Ich habe einen komplexen Klassenbaum, hier wurden teilweise Aspekte und teilweise Algorithmenn vererbt bzw. reimplementiert.
Da durch die tiefe Vererbungshierarchie die Wartung leidet, möchte ich den Baum unter Einsatz des Decorator Patterns in Kombination mit dem Strategy Pattern umbauen.
Nun die Frage:
Ich stelle mir vor für alle Klassen im aktuellen Vererbungsbaum, in die sich nur durch spezielle Implementierungen in virtuellen Methoden unterscheiden die Strategy anzuwenden.
Für Erweiterungen der Funktionalität der Basisklasse würde ich gern den Decorator einsetzen. Wenn ich die Dekoratoren nun so definiere, dass sie neue Methoden zur Basisklasse oder dem BasisInterface hinzudefinieren, dann sind diese für den Nutzer ja nur dann verwendbar, wenn er das spezielle Interface des erweiternden Decorators kennt und nutzt. Damit kann ich die Dekoratoren aber nicht mehr schachteln.
Beispiel:
BasisInterface IBase{ void Foo();}
Spezieller Decorator implementiert IBase und bietet IPrintable{ void Print();}
Ein weitere spezieller Decorator implementiert auch IBase und bietet zusätzlich ICopy{ void Copy();}
Wenn ich nun beide kombinieren möchte (und das ist ja die Motivation hinter dem Decorator, würde ich gern schreiben new SpezDecoratorA( new SpezDecoratorB( xy )) und dann sowohl die Methode Print() als auch Copy() zur Verfügung haben.
Das geht aber nicht, da die neuen Methoden ja im Basis-Decorator nicht bekannt sind.
Eine weitere Frage, die ich mir in dem Zusammenhang stelle: wie vermeide ich, dass ich beim Erstellen der Decoratoren nicht den ursprünglichen Klassenbaum in einer ähnlichn tiefen Decotator-Hierarchie nachbaue?
Hat hier jemand einen Tipp?
Da durch die tiefe Vererbungshierarchie die Wartung leidet, möchte ich den Baum unter Einsatz des Decorator Patterns in Kombination mit dem Strategy Pattern umbauen.
Nun die Frage:
Ich stelle mir vor für alle Klassen im aktuellen Vererbungsbaum, in die sich nur durch spezielle Implementierungen in virtuellen Methoden unterscheiden die Strategy anzuwenden.
Für Erweiterungen der Funktionalität der Basisklasse würde ich gern den Decorator einsetzen. Wenn ich die Dekoratoren nun so definiere, dass sie neue Methoden zur Basisklasse oder dem BasisInterface hinzudefinieren, dann sind diese für den Nutzer ja nur dann verwendbar, wenn er das spezielle Interface des erweiternden Decorators kennt und nutzt. Damit kann ich die Dekoratoren aber nicht mehr schachteln.
Beispiel:
BasisInterface IBase{ void Foo();}
Spezieller Decorator implementiert IBase und bietet IPrintable{ void Print();}
Ein weitere spezieller Decorator implementiert auch IBase und bietet zusätzlich ICopy{ void Copy();}
Wenn ich nun beide kombinieren möchte (und das ist ja die Motivation hinter dem Decorator, würde ich gern schreiben new SpezDecoratorA( new SpezDecoratorB( xy )) und dann sowohl die Methode Print() als auch Copy() zur Verfügung haben.
Das geht aber nicht, da die neuen Methoden ja im Basis-Decorator nicht bekannt sind.
Eine weitere Frage, die ich mir in dem Zusammenhang stelle: wie vermeide ich, dass ich beim Erstellen der Decoratoren nicht den ursprünglichen Klassenbaum in einer ähnlichn tiefen Decotator-Hierarchie nachbaue?
Hat hier jemand einen Tipp?
|
1 |
2 Antworten
Zum Decorator im Allgemeinen könnte dir ein Kapitel von Head First Design Patterns weiter helfen. Dein Beispiel kommt dem Strategy Pattern näher. Ein Objekt verwendet IPrintable wenn es gedruckt werden soll und ICopy wenn es kopiert werden soll. Die Decoratoren die IPrintable oder ICopy implementieren könnten definieren nur wie das Drucken oder Kopieren im einzelnen ausgeführt werden soll.
Wenn also ein Objekt IPrintable verwendet, kann es drucken wenn die IPrintable Eigenschaft zugewiesen wurde. Das ist Strategy, auch hier könnte man durch Zuweisung verschiedener Instanzen definieren wie gedruckt werden soll. Wenn diese IPrintable Implementierungen aber wiederum gleichartige Funktionen ausführen (z.B. Header drucken, Logo drucken, etc.) macht es Sinn diese als Decorator auszulagern. Dann kann ein SimplePrint:IPrintable oder ListPrint:IPrintable beispielsweise mit "Logo drucken" decoriert werden. Ich sehe hier keine sich bildende Decorator Hierarchie.
Wenn also ein Objekt IPrintable verwendet, kann es drucken wenn die IPrintable Eigenschaft zugewiesen wurde. Das ist Strategy, auch hier könnte man durch Zuweisung verschiedener Instanzen definieren wie gedruckt werden soll. Wenn diese IPrintable Implementierungen aber wiederum gleichartige Funktionen ausführen (z.B. Header drucken, Logo drucken, etc.) macht es Sinn diese als Decorator auszulagern. Dann kann ein SimplePrint:IPrintable oder ListPrint:IPrintable beispielsweise mit "Logo drucken" decoriert werden. Ich sehe hier keine sich bildende Decorator Hierarchie.
|
761 ● 1 ● 5 |
Also das Decorator Pattern seh ich für diese Aufgabe gänzlich ungeeignet, da mit diesem Pattern keine Klassen erweitert werden. Das Pattern benutzt man eher um Properties später nacheinander abzuarbeiten/zu addieren oä. Man könnte so zum Bsp. einen Warenkorb aufbauen... man hat ein Warenkorb Objekt und umschließt das mit einem Artikel Objekt und noch einem Artikel usw. ...am Ende kann man dann die einzelnen Schalen abarbeiten/summieren usw.
Grüßle
Grüßle
|
298 ● 4 |
