Ähnliche Frage: Include von Konstanten.
-
Hobbyprogrammierer schrieb:
aber eine abstrakte Basisklasse "Bauteil" zu konstruieren (das geht natürlich),
die alle Eigenschaften der realen Bauteile besitzt, geht nicht.Sowas will ja auch niemand haben, der verstanden hat wie Vererbung funktioniert. Ich will nur das nötige Interface bereitstellen. Alles andere machen natürlich weiterhin die konkreten Bauteile.
die Idee von MichaelE gefällt mir auch sehr gut. Warum können eigentlich Wechselwirkungen nur über zyklische Abhängigkeiten, aber nicht über eine Indirektion, nämlich die Schaltung, simuliert werden?
Lies doch mal ein beliebiges OOP-Buch, da steht auch drin, was von zyklischen Abhängigkeiten zu halten ist. Vielleicht mal ein paar generelle Probleme von zyklischen Abhängigkeiten: Man kann nur schwierig testen, Wiederverwendung ist praktisch unmöglich, wenn man nur einen Teil davon benutzen möchte. Zuguterletzt sind hierarchische Systeme (eben solche ohne zyklische Abhängigkeiten) deutlich leichter zu verstehen.
-
eigentlich braucht er ja keine zyklischen abhängigkeiten o.ä. sondern einfach nur ein paar konstanten-definitionen die von überall erreichbar sind. oder nicht?
-
Hobbyprogrammierer schrieb:
PS. wenn man Bücher über OOP mit anderen Sprachen als C++ liest, dann
wird man feststellen, daß die wechselseitige Beeinflussung von Objekten
nicht nur unerwünscht, sondern sogar Design-Prinzip der OO ist. In Smalltalk
würde man niemals zwei Klassen zu einer vereinigen, nur weil die beiden
über messages eng gekoppelt sind.was hat das mit zyklischen abhängigkeiten zu tun? echte zyklische abhängigkeiten (um entität X definieren zu können, muss die definition von Y bekannt sein und umgekehrt) sind nicht erlaubt (außer ggf. für inline funktionen - dort ist aber der compiler für die auflösung zuständig). falsche abhängigkeiten entstehen in 95% der fälle nur, weil versucht wird, bereits beim definieren einer klasse funktionen inline zu definieren. die restlichen 5% entfallen auf etwas kompliziertere konstruktionen, die aber prinzipiell denselben fehler begehen. außerhalb von funktionen werden vollständige typen werden in C++ schließlich nur zur definition von variablen benötigt (nicht aber zu deren deklaration!) oder wenn eine klasse basisklasse einer anderen sein soll.
-
Hallo
wie dem auch sei, das Ziel der OOP besteht darin, ein kleines "Universum"
aus miteinander kommunizierenden Objekten zu schaffen, und dabei sind zyklische Abhängigkeiten der Art "Objekt der Klasse A ruft Methode auf Objekt der Klasse B auf" und umgekehrt "B Methoden von A" ganz natürlich und ich sehe nicht, wieso das ein Design-Fehler sein soll. Mag sein, daß das in C++ Schwierigkeiten macht; C++ ist allerdings auch keine reine OO-Sprache; in "reinen" OO-Sprachen wie Smalltalk oder (annähernd "rein") Ruby sind solche Arten von Objektkommunikation jedenfalls problemlos.Noch ein Beispiel: Das Prinzip Model-View-Controller besteht aus drei Klassen,
die im "Dreiecksverhältnis" kommunizieren (Controller ruft Methoden des GUI auf,
GUI liefert Rückgabewerte an Model, Model berechnet neuen Wert und gibt diesen
an Controller).Grüße und schönes Wochenende
-
Hobbyprogrammierer schrieb:
Noch ein Beispiel: Das Prinzip Model-View-Controller besteht aus drei Klassen,
die im "Dreiecksverhältnis" kommunizieren (Controller ruft Methoden des GUI auf,
GUI liefert Rückgabewerte an Model, Model berechnet neuen Wert und gibt diesen
an Controller).Schau's Dir nochmal an. MVC entkoppelt Dinge. Die Dreieckskommunikation gibt's nicht. Model und GUI kennen sich nicht und haben auch nicht miteinander zu tun. Sie werden nur über den Controller zusammengehalten. Der einzige der beides kennt ist der Controller. Die Kommunikation von Model/View zu Controller läuft zumeist über ein abstraktes Interface zur Verarbeitung von Messages, sodaß Model/View die konkrete Implementierung des Controllers nicht kennen.
Ich sage ja auch nichts dagegen, daß Objekte der Klasse A Objekte Methoden von Objekten der Klasse B aufrufen und umgekehrt. Das dürfen sie gerne tun, solange wenigstens in einer Richtung durch ein Interface/Basisklasse entkoppelt wurde.
-
Jester schrieb:
Ich sage ja auch nichts dagegen, daß Objekte der Klasse A Objekte Methoden von Objekten der Klasse B aufrufen und umgekehrt. Das dürfen sie gerne tun, solange wenigstens in einer Richtung durch ein Interface/Basisklasse entkoppelt wurde.
Wer den Sinn hier nicht gleich erkennt, dem empfehle ich das Studium des Dependency Inversion Principles. Wobei das eigentlich gerade unseren OOP-Freunden bekannt sein sollte.