Dekorateur Muster von Head First Book falsch verwendet?

Question

Momentan lese ich "Head First Design Patterns". Wie Sie auf den Seiten 24 und 25 der PDF sehen können, habe ich im angegebenen Beispiel Zweifel.

Warum gehen wir nicht machen so etwas wie:

public abstract class Beverage { 

String description = "Unknown Beverage"; 
Double cost; 
ArrayList<Topping> toppings; // allows duplicates 


public void addTopping(Topping topping){ 
toppings.add(topping); 
cost+=topping.getCost(); 
} 
getter/setter of description 
getter/setter of cost 
} 



Public class Topping{ 
String description; 
double cost; 

    getter/setter of description 
    getter/setter of cost 

} 

Dann die Beantwortung von Fragen auf Seite 25:

• Preisänderungen für Gewürze werden uns Code zu ändern, zwingen bestehende

  nein, wir können die Kosten für den Belag durch setter nicht manipulieren.

• Neue Würzmittel werden uns zwingen, neue Methoden zu addieren und die Kostenmethode in der übergeordneten Klasse

  nicht zu ändern, das Verfahren ist das gleiche.

• Was ist, wenn ein Kunde einen doppelten Mokka möchte?

  kein Problem

Hier können wir auch Builder Muster hinzufügen.

Warum sollten Sie das Decorator-Muster in diesem Szenario verwenden? Ist meine Lösung nicht genug?

Answer 1

Ihre Lösung macht Getränke nicht agnostisch zum Topping. Dies ist eine Frage der Design-Wahl meiner Meinung nach, aber das Decorator-Muster wird sicherstellen, dass Ihre Klassen nie voneinander wissen müssen. Außerdem besteht ein höheres Risiko, dass Implementierungsänderungen zu Codeänderungen führen. Später im Buch (und es ist ein ausgezeichnet Buch), werden Sie sehen, dass Sie möchten, dass jede Klasse einen Job hat und so wenig wie möglich andere Klassen kennt.

Ich würde immer noch mit dem Dekorateur gehen, obwohl in solch einem vereinfachten Beispiel ist es schwer, die Vorteile zu sehen.