Interne vs. externe Speicherung von Daten

[Marco13]

Hallo

Eine etwas philosophische Fragestellung, aber mich würde mal interessieren, wie da die allgemeine Meinung ist:

Beim Entwurf von Klassen und ihren Verbindungen hat man oft die Wahl, Eigenschaften von Objekten "intern" oder "extern" zu speichern. Mit "intern" ist hierbei gemeint, dass die Eigenschaft z.B. einfach als Feld in der Klasse liegt, und über einen Getter abgefragt werden kann. Mit "extern" ist gemeint, dass man einzelnen Objekte z.B. mit einer Map oder auch einer 'Function' die Eigenschaft zuordnen kann.

Speziell in frühen Planungsphasen finde ich es schwer, eine Entscheidung zu treffen. (Diese Frage tritt hauptsächlich auf, wenn man auf vielen Objekten des gleichen Typs unterschiedlichste, komplexe Operationen ausführen will). Man kann bei beiden Ansätzen Vor- und Nachteile ausmachen:

Intern:
+ Man hat alles an einer Stelle, eine klare Schnittstelle z.B. durch sprechende Methodennamen, und das ganze ist intuitiv und auch ohne "Überblick über das Gesamtsystem" zu verwenden (einfach mal [c]object.[/c] eintippen, und schauen, was so in der Liste steht ("Ah, 'getGraphics', genau das hab' ich gesucht!" :joke: ))
- Vergleichsweise unflexibel und starr: Man kann keine neuen Eigenschaften hinzufügen oder wegnehmen, ohne dass die Schnittstelle sich ändert. Eigenschaften, die nur in sehr speziellen Zusammenhängen (z.B. lokal in einer bestimmten Methode) gebraucht werden, sind trotzdem für alle sichtbar, weil sie ja "Teil des Objektes" sind.

Extern: (eigentlich genau das inverse zu 'Intern' )
+ Man kann sich seine Eigenschaften und beliebige Zusatzinformationen so zusammensetzen, wie man sie braucht. Die Eigenschaft selbst kann z.B. als Map irgendwo hin übergeben werden, und ggf. auch "von außen" geändert werden, ohne dass man die Objekte selbst verändert oder auch nur kennen muss
- Die Struktur und Semantik der modellierten Objekte geht u.U. verloren. Wenn man alles darüber abbilden würde, bräuchte man keine Klassen mehr, sondern nur noch ID-Objekte und einen Haufen Maps :autsch:

Ggf. kann ich auch auch ein Beispiel nennen, aber dann passiert es wohl leicht, dass man sich daran aufhängt und sich auf "zu spezifische" Lösungsansätze konzentriert. Gibt es irgendwelche allgemeinen Gedanken, Strategien oder gar best practices dazu?

 

[schlingel]

Die Frage ist doch ob sich die "Schnittstelle" zur Laufzeit ändern soll oder nicht. Das ist selten der Fall weshalb ich das als Property implementieren würde.

Wenn ich Punkte habe, die sich zur Laufzeit ändern sollen dann wird es eine Map.

Alles andere hat für mich in Java nicht wirklich einen Sinn :autsch: Soll es sich nicht zur Laufzeit ändern und du implementierst da irgendetwas mit Map würde ich sagen YAGNI und KISS wurden missachtet.

In Sprachen wie z.B. JavaScript schaut's anders aus, da man sich dort ja aussuchen kann ob man etwas mit obj.attr anspricht oder mit obj["attr"].

 

[Marco13]

Es geht nicht (nur) um die Frage, ob die Änderung zur Laufzeit passieren soll. Wenn ein Objekt in vielen verschiedenen Zusammenhängen gebraucht wird, und in jedem dieser Zusammenhänge ggf. höchst-spezifische Informationen mit diesem Objekt assoziiert sein sollen, solle man ja nicht "alles, was irgendwo irgendwann von irgendwem" mal gebraucht wird mit in das Objekt packen. Und insbesondere ist das gar nicht immer möglich, wenn das Objekt aus einer Bibliothek stammt, die man nicht einfach anpassen kann.
...
Hm. Da es sich mir schon fast selbst aufdrängt, jetzt Wrapper-Klassen und Decorators zu erwähnen, vielleicht doch mal ein Beispiel: Agenommen, man wollte einen Graphen visualisieren. Welche Eigeschaften gehören dann in den Knoten? Größe? Farbe? Beschriftung? Ob er "selected" ist? Vielleicht braucht jemand noch eine Schriftart für die Beschriftung, oder eine Farbe für den Text, oder eine Füll- und eine Randfarbe. Es ist weder praktikabel noch annähernd sinnvoll, all diese Informationen in eine riesige, sich für jeden Anwendungsfall ständig ändernde "Node"-Klasse zu packen...