vector mit Interface Klasse
-
Ganz typischer Thread für Euch, ich rate Euch nur geht in ein besseres Forum...
-
mgaeckler schrieb:
volkard schrieb:
Mir scheint, es ist nur double dispatching, was Du baust.
Nein darum geht es nicht. Das ist was anderes. Auch wenn die Probleme ähnlich sind. Beim double dispatching geht es darum eine passende Methode in Abhängigkeit von mehr als einem Objekttyp aufzurufen. Hier habe ich aber nur ein Objekt. Die Actionklassen dienen ausschließlich dem Dispatchmechanismus haben selbst aber keine einzige Membervariable. Es ging einfach darum, daß es möglich sein mußte, das System zu erweitern ohne auch nur eine einzige Zeile im vorhandenen Quelltext zu ändern. Einfach ein neues Modul hinzubinden, fertig.
Wer Plugin Systeme baut, ist selber Schuld. Natürlich fängt man sich alle Arten von Designentartungen ein, wenn man Haarscharf am inner platform anti-pattern entlangcodet. Wenn man erstmal das Design so aufbaut, dass kein Objekt etwas über seine Umgebung annehmen darf, dann muss man mit dem Informationsverlust umgehen. Das heißt aber nicht, dass der Informationsverlust selbst gutes Design ist.
Die einzige Stelle, wo ich dynamic_cast akzeptabel finde ist dort, wo man aktiv den "Objekt-Graphen", also die Objekte und ihre Verbindungen untereinander modifiziert. Ein Beispiel dafür sind Optimierungen. Wenn ich zum Beispiel weiß, dass eine bestimmte Objektkombination wesentlich effizienter durch ein kombiniertes Objekt darstellbar ist (zum Beispiel mathematischer Spezialfall), dann muss ich mir zuerst alle Objekte anschauen, ihre Abhängigkeiten analysieeren und dann durch ein neues Objekt austauschen. Das geht nicht ohne dynamische Typinformation zur Laufzeit.
-
Ja, ist schon ziemlich WTF hier...
otze schrieb:
Wer Plugin Systeme baut, ist selber Schuld.
Was für eine super-unnütze Aussage.
otze schrieb:
Natürlich fängt man sich alle Arten von Designentartungen ein, wenn man Haarscharf am inner platform anti-pattern entlangcodet. Wenn man erstmal das Design so aufbaut, dass kein Objekt etwas über seine Umgebung annehmen darf, dann muss man mit dem Informationsverlust umgehen. Das heißt aber nicht, dass der Informationsverlust selbst gutes Design ist.
Separation of concerns ist also schlecht? Is ja ganz was neues...
-
hustbaer schrieb:
Separation of concerns ist also schlecht? Is ja ganz was neues...
Wenn man zuerst alles versteckt und dann workarounds schreibt, weil man zu viel versteckt hat...ja, dann ist das eine ideale Implementation von Separation of concerns. Denn offensichtlich haben Objekte nichts miteinander zu tun, wenn man es ihnen möglichst schwer macht, notwendige informationen über andere Objekte zu erhalten. Es ist garantiert keine falsche Abstraktionsebene.
