Es gibt das alte, aber weise Sprichwort "Wertkomposition über Vererbung". Ich habe versucht, dies zusammen mit anderen OOPs und Design-Patterns für die letzten Projekte anzuwenden, an denen ich beteiligt war.
Für die meisten Fälle hat es gut funktioniert und irgendwie gut ausgesehen. Aber ich habe bemerkt, dass es manchmal nur 2 oder 3 Klassen gibt, die wirklich das Beste daraus machen, während andere 10+ Klassen plötzlich zu einfachen Delegatoren werden, mit kleinen sich ändernden Details.
Manchmal versuche ich, dies zu beheben, indem ich eine abstrakte Klasse mit den unveränderlichen Details verwende, die die verschiedenen an die konkreten Implementierungen delegiert, aber etwas fühlt sich nicht richtig an.
Wie halten Sie das im Gleichgewicht und folgen Sie gleichzeitig dem alten weisen Sprichwort? Mache ich etwas falsch?
Ich denke, Ihr Problem könnte sein, dass Sie versuchen, dem "alten weisen Sprichwort" zu folgen. Sie kennen wahrscheinlich die Anforderungen der Anwendung viel besser als allgemeine Richtlinien.
Nachdem Sie einige Erfahrung gesammelt haben, um Anwendungen zu erstellen, sollten Sie ein natürliches Gefühl dafür bekommen, wie Sie etwas tun können. Die Anleitungen sind genau das, Anleitungen, die Ihnen helfen, ein Konzept zu verstehen. Sie sind keine Regeln an sich.
"Wertzusammensetzung über Vererbung" ist ein altes Sprichwort, das auch heute gilt. Zusammensetzung und Vererbung sollen die wiederverwendbare & amp; um doppelten Code zu reduzieren. Die Vererbung hat auch andere Vorteile.
Komposition bedeutet, wenn Sie eine generische Methode haben, die zu zwei oder mehr Klassenhierarchien gehört, trennen Sie sie als neue Klasse und lassen Sie die Klassenhierarchien diese neue Klasse als Teil der Komposition haben. Damit berühren Sie die Klassenhierarchie noch nicht, Sie profitieren von wiederverwendbarem Code.
%Vor%Im obigen Beispiel können alle Aves (Vögel) fliegen (), (flugunfähige Vögel wie Penguin oder Dodo können immer noch fliegen () ohne fliegen). Aber Fledermaus, die ein Säugetier ist, kann auch fliegen ()
Sie können jetzt Fly () als separate Klasse herausziehen und die Komposition über die Vererbung (einschließlich Fly () als Teil von Aves) favorisieren
%Vor%FlyBehavior kann beispielsweise eine Klassenhierarchie mit ShortFlightBehavior und LongFlightBehavior sein.
Ich hoffe, ich habe Sie nicht weiter verwirrt:)
Wann aufhören? Hören Sie auf, sich überhaupt auf die Komposition zu konzentrieren. Es wird natürlich kommen, wenn Sie sich auf andere Regeln konzentrieren.
Konzentrieren Sie sich auf "is-a" und SRP, um stattdessen eine korrekte Vererbung zu erhalten.
Die einfachste Möglichkeit, SRP für Klassen zu überprüfen, besteht darin, den Methodennamen mit dem Klassennamen zu verknüpfen.
%Vor% Die Methode WriteLog kann nicht wirklich mit Vehicle verknüpft werden. Brechen Sie es aus und nehmen Sie es stattdessen durch den Konstruktor auf (Komposition und Abhängigkeitsinjektion).
Es klingt, als würden Sie die heuristische Weisheit in ein Absolutes verwandeln. Es sagt Ihnen nicht "nie", Vererbung zu verwenden. Wenn Sie sich in einer Situation befinden, in der Vererbung oder Komposition gleich gut funktionieren, verwenden Sie Komposition. Einfach.
Tags und Links design-patterns design oop composition