# OO-Prinzipien



## maximilius (24. Mrz 2009)

Ich möchte in diesem Thread ein paar OO-Prinzipien auflisten und mit eurer Hilfe herausfinden, warum man sie einhalten sollte.

Neben mir liegt das Buch

Entwurfsmuster von Kopf bis Fuß
O'Reilly Verlag
4. korrigierter Nachdruck 2008

Auf Seite 608 sind OO-Prinzipien aufgelistet.
Diese klingen alle recht sinnvoll, aber wenn mich ein Freund oder Kommilitone fragt, warum man sie einhalten sollte, kann ich darauf nur sehr schwammig antworten und deshalb suche ich nun kurze und knappe Begründungen, warum man sie einhalten sollte.

Die OO-Prinzipien:
(1) Kapseln Sie das, was variiert
(2) Ziehen Sie die Komposition der Vererbung vor.
(3) Programmieren Sie auf eine Schnittstelle, nicht auf eine Implementierung.
(4) Streben Sie für Objekte, die interagieren, nach Entwürfen mit lockerer Bindung
(5) Klassen sollten für Erweiterung offen, aber für Veränderung geschlossen sein.
(6) Stützen Sie sich auf Abstraktionen. Stützen Sie sich nicht auf konkrete Klassen.
(7) Sprechen Sie nur mit Ihren Freunden.
[noparse](8)[/noparse] Versuchen Sie nicht, uns anzurufen, wir rufen Sie an.
(9) Eine Klasse sollte nur einen Grund haben, sich zu ändern

Meine Erklärungsversuche:
(6) Wenn ich einen Algorithmus auf einer abstrakten Ebene programmiere, kann ich ein und den selben Algorithmus für mehrere konkrete Fälle verwenden. Hätte ich einen Algorithmus für eine konkrete Implementierung geschrieben, könnte ich ihn nicht auf ähnliche anwenden.
[noparse](8)[/noparse] Würde ich nicht das Beobachter-Muster einsetzen, müsste ich ständig in bestimmten Intervallen alle zu beobachtenden Objekte auf Änderung abfragen. Wenn ich das Beobachter-Muster einsätze, melden sich die beobachteten Objekte bei mir, wenn sie sich Ändern. (Vergleichbar mit Interrupt-Service-Routinen)

Ihr seht, ich bin mit meinem Latein schnell am Ende.
Einige der aufgelisteten Prinzipien verstehe ich im Moment auch noch nicht 100%ig ... sonst könnte ich sie ja auch erklären.

(2) Habe ich zwar verstanden, kann es aber nicht kurz und knapp widergeben.
Wenn ich sehr viele Klassen habe, die ich versuche in einer Klassenhierarchie abzubilden, wird es desto schwieriger, je mehr verschiedene Verhaltensweisen ich habe, die bei den einzelnen Klassen in unterschiedlichen Kombinationen auftreten. Selbst wenn ich eine Lösung für die Hierarchie gefunden habe, kann es mir passieren, dass bei der Wartung und Erweiterung des Codes eine neue Klasse entsteht, die sich nicht in die gebildete Hierarchie einbetten lässt.
Hm...ob man das versteht, wenn ich wem das an den Kopf knalle? :-(

lg Stephan


----------



## Gast2 (24. Mrz 2009)

Moin,



> aber wenn mich ein Freund oder Kommilitone fragt, warum man sie einhalten sollte, kann ich darauf nur sehr schwammig antworten


die Design-Patterns sind auch nur sehr schwammig (weil sehr abstrakt), also kannst Du auch nur sehr schwammig Antworten ... sie zeigen Dir aber einen Weg ein Problem effizienter zu lösen

hand, mogel


----------



## tfa (24. Mrz 2009)

Zu 8: Mit diesem Spruch wird häufig das Prinzip Inversion of Control beschrieben. Siehe auch Dependency Injection ;-)


----------

