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
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
Zuletzt bearbeitet:
