Ex 6.3
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.
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.
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?
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.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 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
Mal schauen, was bis Montag zu der Aufgabe für Lösungen ankommen.
Die Anforderungen sind deutlich im Text vorhanden: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.
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?
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.
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.
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.
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.
Zuletzt geändert von marcel_b am 7. Dez 2007 18:30, insgesamt 1-mal geändert.
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.
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.
Zuletzt geändert von Bara2 am 7. Dez 2007 20:15, insgesamt 1-mal geändert.
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?Das neue muss auch gehen: Man muss bidirektionale Graphen bauen können.
Zwar gibt es keinen WE-Support, aber vielleicht lässt sich das ja am Montag dann klären
Nein. Aber ohne die Anforderung, der neue Graph müsse bidirektional sein, sieht die Lösung anders aus als mit.ist die Frage "Wie ändere ich das Design damit es konform zu LSP ist" so missverständlich oder schwer?
Schönes WE
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.
Wo genau ist denn das Problem? Das man auch einfach die Anforderung an die Klasse ändern könnte ist wieder eine andere Sache.
bleiben Sie bitte eindeutig bei den Namen.Müssen wir das Design ändern?
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?
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?