Seite 2 von 3

Verfasst: 7. Dez 2007 13:38
von marcel_b
Richtig. Damit ist endlich gesagt, wo das Problem der Erweiterung liegt...

Verfasst: 7. Dez 2007 15:34
von mantra
Wir reden vermutlich aneinander vorbei :)

Wir fragen uns, ob auch unser verbessertes Design nur bidirektionale Netzwerke erlauben soll.
Deine Antwortet lautet "ja" und unsere Frage lautet: "Woher sollten wir das wissen?"

Denn der Aufgabenstellung war es nicht zu entnehmen.
Aber nur wenn jemand rein bidirektionale Graphen erwartet, kommt es zu dem Problem.

Verfasst: 7. Dez 2007 15:34
von tarnschaf
Also die 3.1. kann man auch lösen, so dass der JUnit Testfall fehlschlägt, wenn man das möchte. Mit einer kleinen Änderung in der SimpleAction Klasse (die ja sicher legitim ist), klappt das..

Wir hängen aber auch bei der 3.3. - in dem Moment, wenn wir mit bidirektionale Kanten die bisherigen Klassen erweitern (vererben und überschreiben), verletzen wir das LSP, da dann z.B. die vorhandene Traversierung nicht mehr funktioniert. (bidirektional ist doch automatisch zyklisch ab der ersten Verbindung!)
Wenn wir dagegen einfach das bisherige so belassen, also von Node erben und beispielsweise eine neue Methode erstellen, die dann alle (also predecessors und sucessors) zurückgibt, ist irgendwie nicht klar, warum wir die Klasse überhaupt von den bisherigen vererben sollen.

Und ob wir die Klassen der "Objectville Software Inc." nun ändern dürfen, oder nur umstrukturieren ist uns auch nicht mehr klar. Die Aufgabenstellung sagt nein, (denn 1. man ändert doch ein Framework nicht? 2. hat unser "kollege" das ja auch nicht versucht), im Forum heißt es dagegen alles darf geändert werden, dann könnte man ja aber das Framework unter Umständen nicht mehr nutzen, oder wurde dessen Zukunft in dieser Aufgabe auch in unsere Hände gelegt?

Verfasst: 7. Dez 2007 16:01
von marcel_b
tarnschaf hat geschrieben:Also die 3.1. kann man auch lösen, so dass der JUnit Testfall fehlschlägt, wenn man das möchte. Mit einer kleinen Änderung in der SimpleAction Klasse (die ja sicher legitim ist), klappt das..

Wir hängen aber auch bei der 3.3. - in dem Moment, wenn wir mit bidirektionale Kanten die bisherigen Klassen erweitern (vererben und überschreiben), verletzen wir das LSP, da dann z.B. die vorhandene Traversierung nicht mehr funktioniert. (bidirektional ist doch automatisch zyklisch ab der ersten Verbindung!)
Wenn wir dagegen einfach das bisherige so belassen, also von Node erben und beispielsweise eine neue Methode erstellen, die dann alle (also predecessors und sucessors) zurückgibt, ist irgendwie nicht klar, warum wir die Klasse überhaupt von den bisherigen vererben sollen.

Und ob wir die Klassen der "Objectville Software Inc." nun ändern dürfen, oder nur umstrukturieren ist uns auch nicht mehr klar. Die Aufgabenstellung sagt nein, (denn 1. man ändert doch ein Framework nicht? 2. hat unser "kollege" das ja auch nicht versucht), im Forum heißt es dagegen alles darf geändert werden, dann könnte man ja aber das Framework unter Umständen nicht mehr nutzen, oder wurde dessen Zukunft in dieser Aufgabe auch in unsere Hände gelegt?
Zu 1. Kann ich so nichts zu sagen.

Zu 2. Erster Satz: Ja. Zweiter Satz: Ja. Was soll ich noch dazu sagen? Na klar, man muss die Vererbungshierarchie überdenken... :!:

Zu 3. Wie willst du das LSP Problem lösen ? Dein "Kollege", der den Network-Vorschlag gemacht hat, hat zwar OCP grundsätzlich verstanden und stupide angewendet - aber offensichtlich bei LSP geschlafen. So geht es also nicht. Aber wie macht man es dann? In der Vorlesung habt ihr 2 Beispiele gesehen wie man damit umgehen kann... Beides zieht grundsätzlich Veränderungen der Hierarchie mit sich - mindestens mal von Network und NetworkNode.


Es scheint, als ob die Aufgabe ziemlich viel Kummer macht :cry:
Mal schauen, was bis Montag zu der Aufgabe für Lösungen ankommen.

Verfasst: 7. Dez 2007 16:08
von marcel_b
mantra hat geschrieben:Wir reden vermutlich aneinander vorbei :)

Wir fragen uns, ob auch unser verbessertes Design nur bidirektionale Netzwerke erlauben soll.
Deine Antwortet lautet "ja" und unsere Frage lautet: "Woher sollten wir das wissen?"

Denn der Aufgabenstellung war es nicht zu entnehmen.
Aber nur wenn jemand rein bidirektionale Graphen erwartet, kommt es zu dem Problem.
Die Anforderungen sind deutlich im Text vorhanden:

Das Alte muss immernoch gehen: gerichtete, azyklische Graphen müssen sich modellieren lassen, so das ein Client mit dem gegebene TraversierungsKlassen damit arbeiten kann.

Das neue muss auch gehen: Man muss bidirektionale Graphen bauen können.

Offensichtlich ist aber, dass die Traversierung nur für das eine klappt. Entweder man schränkt die Traversierung auf den einen Typ ein oder man schafft eine Traversierung, die mit beiden umgehen kann. Letzteres kann etwas schwieriger werden und ist nicht gefordert.

ist die Frage "Wie ändere ich das Design damit es konform zu LSP ist" so missverständlich oder schwer? :(

Verfasst: 7. Dez 2007 16:38
von Bara2
Nur noch mal zur Sicherheit:
Wir sollen nichts konkret implementieren sondern uns nur ein Design überlegen, das das LSP nicht mehr verletzt. Dieses Design muss per Klassendiagramm dokumentiert werden.
Oder? :)
Wenn das so ist, muss man sich wirklich nur das Beispiel aus der Vorlesung ansehen und hat die Lösung eigentlich gegeben.

Verfasst: 7. Dez 2007 16:46
von marcel_b
Richtig. Nicht Programmieren. Wenn der Eindruck gerade entstanden sein sollte, tut mir das Leid.

Die Formulierung im O-Ton:

Lösen Sie das Problem. Entwerfen (nicht programmieren) Sie ein neues Design, das konform zum LSP ist. Dokumentieren Sie ihre Lösung mit einem Klassendiagramm. Erklären Sie, warum dieses Design das LSP Problem löst.


Nicht mehr - nicht weniger.

Verfasst: 7. Dez 2007 18:27
von Bara2
Nein?
jetzt bin ich vollends verwirrt. Mit "nicht programmieren" ist doch wohl gemeint, dass wir nichts coden sollen, sondern nur darstellen, wie die Lösung aussieht.
Oder kann ich kein Deutsch mehr :?

/edit: OK, danke für die Klarstellung. Das Missverständnis lag wohl auf meienr Seite.

Verfasst: 7. Dez 2007 18:32
von marcel_b
So, ich hab's nochmal klarer geschrieben...

Nein, es muss nichts programmiert werden
Ja, nur darstellen (Klassendiagramm und so).

Verfasst: 7. Dez 2007 18:42
von mantra
Das neue muss auch gehen: Man muss bidirektionale Graphen bauen können.
Das ist der Punkt: Wo wird das verlangt? Nur, weil der Designvorschlag dies enthält? Ist die Bidirektionalität nicht möglicherweise auch eine schlechte Design-Entscheidung unseres schludrigen Kollegen?
Zwar gibt es keinen WE-Support, aber vielleicht lässt sich das ja am Montag dann klären
ist die Frage "Wie ändere ich das Design damit es konform zu LSP ist" so missverständlich oder schwer? :(
Nein. Aber ohne die Anforderung, der neue Graph müsse bidirektional sein, sieht die Lösung anders aus als mit.

Schönes WE :)

Verfasst: 7. Dez 2007 19:42
von Trigger
Du sollst doch einfach nur den Designvorschlag so ändern, dass das LSP nicht mehr verletzt ist. Die mögliche Funktionalität sollte dabei natürlich erhalten bleiben -> wir wollen also weiterhin Netzwerkknoten, die bidirektional sind.
Wo genau ist denn das Problem? Das man auch einfach die Anforderung an die Klasse ändern könnte ist wieder eine andere Sache.

Verfasst: 8. Dez 2007 08:11
von Evgeni
Hallo,


hab mal eine Frage - eigentlich genügt es NetzwerkNode nicht von Node erben zu lassen, um LSP zu erfüllen.
Damit wäre 3.3 doch schon erfüllt?

Verfasst: 8. Dez 2007 09:17
von marcel_b
nein, dein Code für Network würde nicht kompilieren. Probiers aus.

Verfasst: 8. Dez 2007 23:14
von DaO
... eine Klasse DepthFirstSearch, die eine Breitensuche auf einem gegebenen Knoten startet... :?: bleiben Sie bitte eindeutig bei den Namen.

Müssen wir das Design ändern?

Verfasst: 9. Dez 2007 04:43
von sander
Hallo!

Müssen wir das Design ändern? Warum nicht einfach aus NetworkNode die getPredecessors entfernen und statt dessen einfach eine neue Methode ala "addBidirectionalEdge(Node n)" hinzuzufügen. Diese erzeugt dann die entsprechenden Vorwärts- UND Rückwärtskanten.

Spricht da was dagegen oder habe ich was übersehen?