Zirkuläre Abhängigkeiten auf Klassen-Level

Zirkuläre Abhängkeiten auf Klassen-Ebene sind meist nicht wirklich schlimm, können aber unter Umständen auf ein 'unschönes' Design hinweisen.

Feldmouseadapter vs Feld2d

Feld2D tut sich im Konstruktur beim MouseAdapter? registrieren. Und der Adapter kennt natürlich Wieder Feld.

Lösung: nur noch einen MouseAdapter? übergeben, und keinen ganzen FeldMouseAdapter?

[trunk/doc/design/probleme/feld2d-feldmouseadapter.patch]

Figur2d vs Feld2d

Feld2d sagt der Figur2d sie solle sich doch auf das feld setzen. Anstatt dem Aufruf setzeAuf(Feld) können die Koordianten über x/y übergeben werden.

[trunk/doc/design/probleme/feld2d-figur2d.patch]

Zirkuläre Abhängigkeiten auf Design-Level

Hier ein paar offene zirkuläre Abhängkeiten auf Design-Ebene. Design Ebene bedeutet in dem Zusammenhang auf 'Paket' Ebene. Die meisten sind rein 'organisatorischer' Struktur, sprich sie entstanden nur weil wir unsere Pakete weniger nach 'Design' und mehr nach 'logischer Abgrenzung' organisieren.'

Event / Clients (Level 3 Design Abhängigkeit)

Gewisse Events wissen über den Client bescheid, der Client kennt natürliche Events.

Lösung: Alle Client-Relevanten Events (sprich alle) ins Package app.client verschieben Getestet: ja (geht)

Zuautomat vs client.pd (Level 1 Design Abhängiekit)

Die client.pd kennt den Zugautomaten und umgekehrt. Grund dafür ist, dass im SpielDaten? der Zugautomat als solcher abgelegt is.

Einfache Lösung: Feld Spieldaten.zugAutomat in den Typ 'Automat' umwandlen.

Getset: ja (geht)

Zugautomat vs Zugautomat-Zustaende (Design Abhängigkeit)

Zugautomat kennt Zustaende Zustaende kennen SpielDaetn? Spieldaten sind im Packagae 'Zugautomat'

Lösung: Spieldaten Analog zum Server und Clienten in ein eigenes Package Getestet: ja (geht)

Am Schluss?

Dann wären alle Design (Also Paket-Level) Knäuel aufgelöst, und das ohne irgendwelche 101-Interen Mappings (sogenannte Transformations) - pd ausgeschlossen.

Struktur vorher

Struktur nachher