Übung 5 - Aufgabe 4 -Vorbedingungen / Account-Hierarchie

[CloneCommander]

Hi,

wollte grad Aufgabe 4 Teil 2 angehen (Design umbauen, dass es DbC-Konform wird)

Da habe ich ein Problem. Es wird im Interface Account ja verlangt, dass lineOfCredit immer positiv ist. Das kollidiert ja mit CheckingsAccount, wo es negativ verwendet wird. Selbst wenn alle Klassen Account selbst implementieren und somit Schwierigkeiten mit überschriebenen Methoden ausgeschlossen werden - SavingsAccount verletzt ja immernoch die "unantastbare" Bedingung von lineOfCredit >= 0, oder?

Genauso der JuniorCheckingsAccount. Hier wird im Test eine Konto mit Guthaben 10, lineOfCredit 1000 generiert. Anschließend 2 mal withdraw(10) aufgerufen. Das kann / darf ja garnicht gehen, weil lineOfCredit = 0. Wie soll ich dann bewerkstelligen, dass die Tests durchlaufen?!

Code: Alles auswählen

@Test
	public void testWitdrawFromOpenAccount() throws Exception {
		final Account a = createAndOpenAccount(10, 1000);
		a.withdraw(10);
		a.withdraw(10);
	}

Danke schonmal...

Tibor

[marcel_b]

offensichtlich geht das mit dem bisherigen design nicht... Du musst wohl die Hierarchie & Constraints umbauen...

[CloneCommander]

Dass es nicht geht ist mir klar

Die Constraints in Account DARF man also umformulieren?

Und zu dem zitierten Test: Bei einem JuniorCheckingAccount DARF der doch garnicht durchlaufen, oder? denn lineOfCredit ist ja unabhähgig vom Design per Definition immer 0, oder nicht?!Dann kann ich von einem Konto mit 10GE nicht 20 abheben?!

[marcel_b]

ja. Sie sind scheinbar nicht "gut genug" für die Anforderungen. Checking-Account erfüllt nur die Constraints des Interfaces. Nach LSP müsste sich aber jeder subtyp von Account gleich verhalten (gemäß Spezifikation) Klappt aber offensichtlich nicht.

Was tun? Ändern! Beim Ändern werden (hoffentlich) eine ganze Reihe von Fragen aufkommen wie z.B. wann ist LSP tatsächlich verletzt? Was hat das mit DbC zu tun usw.

[marluwie]

ja. Sie sind scheinbar nicht "gut genug" für die Anforderungen. [...]

Sind mit "Sie" die Spezifikationen oder die Tests gemeint? Oder soll das so ungewiss sein?
Dürfen wir auch die Tests ändern?

Es ist kompliziert Entscheidungen zu treffen, wenn man sich nicht weiß, woran man sich orientieren darf. Wir haben keine Benutzer des Systems, keine Spezifikation vom Auftraggeber (bzw. dürfen diese ändern) und die Tests scheinen nicht auf die Anforderungen zu passen.

EDIT: Ok, wir haben doch einen Client

[CloneCommander]

Lass mich an deinem Wissen Teil haben

Was meinst du mit Client?
Ob sich das "Sie" jetzt auf die Tests bezieht würd ich auch gern wissen

Komme so irgendwie noch nicht weiter.

[andy-held]

In der Aufgabe steht auch:

Jedoch muss ihr Design die dokumentierten Funktionen der drei Account-Subklassen auch im neuen Design erfüllen.

Heißt das, dass unsere Klassen Account implementieren sollen?
Also: sollen die unsere Klassen gleichnamige Methoden haben oder reichen gleichwertige?

[marcel_b]

Eine gemeinsame Oberklasse scheint sinnvoll: Funktionen wie Geld abheben und einzahlen, Konto schließen und öffnen gehören zu einem Bankaccount einfach dazu. Welche Contraints für die jeweiligen Operationen gelten sollen, muss überprüft werden - bzw. gewisse Funktionen gehören vielleicht nicht in die oberste aller Klassen etc. Kommst du ohne jegliche Hierarchie aus, haben wir wohl keine LSP/DbC Aufgabe mehr... das wäre tatsächlich nicht mehr in meinem Sinn

Aber du hast recht: "gleichwertige Methoden" mag für gewissen Anforderungen eine gute Lösung sein - zumindest sehe ich spontan wenigstens einen sinnvollen Fall.

[CloneCommander]

... womit meine Frage zu den Tests leider noch nicht beatwortet ist. Die ganz oben zitierte Testmethode KANN doch bei einem JuniorCheckingAccount garnicht gehen.
Soll ich die Tests umschreiben? (aka "if JuniorCheckingAccount machDenTestNicht()")

Ich verstehe unter diesem Hintergrund nicht, wie man die Aufgabe lösen soll - sorry.

[michael2k5]

hi,
mir stellt sich zu der aufgabe auch noch ne frage:
damit sich die regel, das preconditions der subklassen nur gleich bleiben bzw gelockert werden dürfen, umsetzen lässt, müssten wir für methoden der basisklasse scharfe preconditions formulieren, die dann die preconditions für alle subtklassen beinhalten. nun ist die frage, inwiefern davon die implementierung der methoden in den basisklassen abhängig ist. wenn die methoden dort die schafen preconditions erfüllen, lassen sie sich nicht für alle subklassen wiederverwenden, was zwangsläufig zu dubliziertem code führen würde. um die frage etwas zu konkretisieren...
wir formulieren die precondition der methode setLineOfCredit: "newValue must be 0" (als schärfste precondition, damit die subklassen die preconditions nur lockern bzw gleichhalten)
und wir implementieren die methode als primitiven setter (damit wir sie für alle subklassen wiederverwenden können):

Code: Alles auswählen

	
public void setLineOfCredit(final int newValue) {
		this.lineOfCredit = newValue;
	}

auf der einen seite prüft die methode jetzt nicht die preconditions, was natürlich blöd ist. auf der anderen können wir aber setLineOfCredit in allen klassen wiederverwenden.

[marcel_b]

... womit meine Frage zu den Tests leider noch nicht beatwortet ist. Die ganz oben zitierte Testmethode KANN doch bei einem JuniorCheckingAccount garnicht gehen.
Soll ich die Tests umschreiben? (aka "if JuniorCheckingAccount machDenTestNicht()")

Ich verstehe unter diesem Hintergrund nicht, wie man die Aufgabe lösen soll - sorry.

Ja, umschreiben wenn nötig. Die aktuellen Tests zeigen, dass ein Austausch der Subklassen nicht so ohne weiteres möglich ist. Die bisherigen Tests sowie die assertXY-Anweisungen waren als Hilfestellung für euch gedacht um die Probleme schneller zu finden.

Die Spezifikation jeder Account-Klasse ist in der Dokumentation angegeben. Gegen die könnt ihr (neue) Tests (die ausführbare Spezifikation) schreiben. Die Spezifikationen + Implementierungen müssen allerdings geändert werden um eine LSP/DbC konforme Lösung zu finden.

[marcel_b]

hi,
mir stellt sich zu der aufgabe auch noch ne frage:
damit sich die regel, das preconditions der subklassen nur gleich bleiben bzw gelockert werden dürfen, umsetzen lässt, müssten wir für methoden der basisklasse scharfe preconditions formulieren, die dann die preconditions für alle subtklassen beinhalten. nun ist die frage, inwiefern davon die implementierung der methoden in den basisklassen abhängig ist. wenn die methoden dort die schafen preconditions erfüllen, lassen sie sich nicht für alle subklassen wiederverwenden, was zwangsläufig zu dubliziertem code führen würde. um die frage etwas zu konkretisieren...
wir formulieren die precondition der methode setLineOfCredit: "newValue must be 0" (als schärfste precondition, damit die subklassen die preconditions nur lockern bzw gleichhalten)
und wir implementieren die methode als primitiven setter (damit wir sie für alle subklassen wiederverwenden können):

Code: Alles auswählen

	
public void setLineOfCredit(final int newValue) {
		this.lineOfCredit = newValue;
	}

auf der einen seite prüft die methode jetzt nicht die preconditions, was natürlich blöd ist. auf der anderen können wir aber setLineOfCredit in allen klassen wiederverwenden.

Hilft das Verzichten auf die assertXY Statements?

[marluwie]

Lass mich an deinem Wissen Teil haben
Was meinst du mit Client?

Schau dir mal an, wie die Tests geschrieben wurden.

[CloneCommander]

Hm, danke für die Antwort Marcel.

War leider heute den ganzen Tag unterwegs, durch die Problematik mit den Tests hab ich keinen Einstieg in die Aufgabe gefunden, konnte jetzt auch nicht mehr nachbessern. Das Design ist umgebaut, die Tests aber nicht angepasst. (Wenn die eh nur als Hilfe gedacht waren - was bei mir leider das Gegenbteil bewirkt hat - wird das glaube ich ja eh nicht Teil der Aufgabe sein.)
Aber zumindest hat das dazu geführt, sich ausführlich mit der Problematik zu beschäftigen

Bis morgen!

Tibor