Seite 1 von 1

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

Verfasst: 26. Nov 2009 14:56
von 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

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

Verfasst: 27. Nov 2009 12:20
von marcel_b
offensichtlich geht das mit dem bisherigen design nicht... Du musst wohl die Hierarchie & Constraints umbauen...

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

Verfasst: 27. Nov 2009 13:14
von 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?!

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

Verfasst: 27. Nov 2009 13:28
von 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. :)

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

Verfasst: 27. Nov 2009 17:20
von marluwie
marcel_b hat geschrieben: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 :)

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

Verfasst: 28. Nov 2009 11:35
von 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.

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

Verfasst: 29. Nov 2009 09:20
von 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?

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

Verfasst: 29. Nov 2009 11:48
von 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.

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

Verfasst: 29. Nov 2009 15:19
von 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.

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

Verfasst: 29. Nov 2009 15:52
von 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.

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

Verfasst: 30. Nov 2009 09:30
von marcel_b
CloneCommander hat geschrieben:... 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.

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

Verfasst: 30. Nov 2009 09:34
von marcel_b
michael2k5 hat geschrieben: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?

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

Verfasst: 30. Nov 2009 16:53
von marluwie
CloneCommander hat geschrieben:Lass mich an deinem Wissen Teil haben :)
Was meinst du mit Client?
Schau dir mal an, wie die Tests geschrieben wurden.

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

Verfasst: 30. Nov 2009 23:32
von 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