Autonomie von Klassen

[createLife()]

Hallo liebe Entwickler Gemeinde,

ich programmiere seit einigen Jahren in Java und ich schlage mich eigentlich von Anfang an bis heute mit dem Problem herum, dass früher oder später immer mehr Abhängigkeiten zwischen meinen Klassen bestehen, die ich nicht lösen kann und ich somit keine modulare Software mehr habe.

Natürlich arbeite ich nach dem "DRY" Prinzip, versuche sinnvolle Klassenhierarchien aufzubauen, organisiere zusammengehörende Klassen in entsprechenden packages, definiere geeignete interfaces, um Teilfunktionalität dort zur Verfügung zu stellen, wo sie gebraucht wird. Bis zu einem gewissen Punkt gelingt es mir auch ganz gut, meine Programme "schön" aufzubauen. Oft komme ich dann aber in Situationen, wo eine Instanz einer ich nenne es mal "Hauptklasse" existiert, die eine Menge anderer Instanzen referenziert, meist auch noch mit Backreferenz, da ich von den referenzierten Instanzen aus auch die Funktionalität der "Hauptklasse" benötige.

Ich finde das äußerst unschön. Zum ersten habe ich dadurch immer aufgeblähtere Konstruktoren mit zig Parametern, zum zweiten eine sehr hohe Zahl an Instanzvariablen und zum dritten eine unerfreulich enge Verzahnung von Komponenten - all dies erschwert Wartbarkeit und Pflege.

Ich bin ratlos, wie man diese Problematik am geschicktesten löst. Selbstverständlich ist sowas sicherlich sehr anwendungsabhängig, aber das ist mir jetzt schon häufiger in verschiedenen Anwendungen passiert, z.B. letztens bei einer GUI:

ich habe eine Darstellungskomponente, ein "MainView extends JPanel", die eine Vielzahl von anderen Komponenten darstellen und verwalten soll, in verschiedene Zustände versetzt werden kann und je nach Zustand auf Nutzereingaben anders reagiert. Mit der Zeit füllte sich "MainView" mit zahlreichen Instanzvariablen: Component Listen, custom Filechoosern, Dialogfenstern, Key Mappings und MouseListeners. Für die Ereignisbehandlung brauchte ich Zugriff auf "MainView", da sich Komponenten gegenseitig beeinflussen können - ich habe es also so realisiert, dass diese über "MainView" miteinander kommunizieren.

Vielleicht habt ihr ja ganz allgemeine Tipps, Anregungen oder "best practices", wie man Modularität im Entwicklungsprozess gewährleistet und derlei Fallstricke vermeidet.

Grüße und danke fürs Lesen!

 

[Marco13]

Uhrzeitbedingt nicht sooo ausführlich:

Dass die "Hauptklasse" von den "Hilfsklassen" abhängig ist, ist ja normal. Allerdings ... ach, ein Bild sagt mehr als 1000 Worte:

"Star" und "Tree" sind OK, aber bei "Mesh" oder "Fully Connected" hat man was falsch gemacht

Da sind jetzt halt keine Richtungen eingezeichnet, aber die sind schon wichtig: Wenn eine "Hilfsklasse" von der "Hauptklasse" abhängig ist, ist das natürlich schlecht und schränkt die Wiederverwendbarkeit ein. In manchen Fällen (speziell wenn du von GUI redest) ist da eine Gegenmaßnahme, sich vernünftige (Modellklassen und) Listener zu überlegen. Plakativbeispiel: Ein Button, der eine Aktion in der "Hauptklasse" ausführen soll, muss nicht die Hauptklasse kennen, sondern nur irgendeinen ActionListener...

 

[anonym]

Etwas ausführlicher, aber prinzipiell das sellbe:

Sieh dir mal die Design Patterns an. Da gibt es einige ganz nette Ideen, wie man Abhängigkeiten organisieren kann. Marco13's Star wäre zum Beispiel ein Mediator. Also ein Objekt, dessen Aufgabe darin besteht, die Kommunikation zwischen Objekten zu regeln.

Wenn du mit Packages arbeitest, bietet sich eventuell eine Fascade an, also eine Klasse, deren Aufgabe darin besteht Zugriffe auf eine zugrunde liegende Klassenstruktur entgegen zu nehmen und zu beantworten. Klassen, die das brauchen, greifen dann nurnoch auf die Fascade zu (und sind nurnoch von dieser abhängig), nicht mehr auf die Unterklassen.

Gerade in GUI's solltest du dir auch MVC (Model - View Controll) ansehen. Über das Observer Pattern und einen "Controller" werden hier View und Model unabhängig.

Interessant sein könnten auch Interfaces, eventuell im Zusammenhang mit Dependency Injection. Schaffst du für eine Klasse ein Interface, so ist Code, der die Klasse nutzt, vom Interface abhängig. Nicht von der Klasse selbst.