Ex 6.3

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag von marcel_b »

Richtig. Damit ist endlich gesagt, wo das Problem der Erweiterung liegt...

Benutzeravatar
mantra
Computerversteher
Computerversteher
Beiträge: 385
Registriert: 23. Okt 2005 23:56
Wohnort: Wiesbaden

Beitrag 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.

Benutzeravatar
tarnschaf
Erstie
Erstie
Beiträge: 19
Registriert: 6. Jan 2005 00:58
Wohnort: Aschaffenburg
Kontaktdaten:

Beitrag 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?

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag 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.

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag 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? :(

Bara2
Mausschubser
Mausschubser
Beiträge: 54
Registriert: 11. Nov 2005 13:41

Beitrag 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.

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag 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.
Zuletzt geändert von marcel_b am 7. Dez 2007 18:30, insgesamt 1-mal geändert.

Bara2
Mausschubser
Mausschubser
Beiträge: 54
Registriert: 11. Nov 2005 13:41

Beitrag 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.
Zuletzt geändert von Bara2 am 7. Dez 2007 20:15, insgesamt 1-mal geändert.

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag von marcel_b »

So, ich hab's nochmal klarer geschrieben...

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

Benutzeravatar
mantra
Computerversteher
Computerversteher
Beiträge: 385
Registriert: 23. Okt 2005 23:56
Wohnort: Wiesbaden

Beitrag 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 :)

Benutzeravatar
Trigger
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 230
Registriert: 21. Apr 2004 19:57
Wohnort: Malchen

Beitrag 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.

Evgeni
Windoof-User
Windoof-User
Beiträge: 39
Registriert: 1. Dez 2004 19:22

Beitrag 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?

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Beitrag von marcel_b »

nein, dein Code für Network würde nicht kompilieren. Probiers aus.

DaO
Windoof-User
Windoof-User
Beiträge: 40
Registriert: 9. Mär 2007 17:27

Beitrag von DaO »

... eine Klasse DepthFirstSearch, die eine Breitensuche auf einem gegebenen Knoten startet... :?: bleiben Sie bitte eindeutig bei den Namen.

sander
Nichts ist wie es scheint
Beiträge: 23
Registriert: 2. Dez 2003 16:42

Müssen wir das Design ändern?

Beitrag 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?

Antworten

Zurück zu „Archiv“