Builder design pattern: po co nam dyrektor?

Jeśli rozdzielisz na Director I Builder, udokumentowałeś różną odpowiedzialność za montaż produktu od zestawu części (director) i odpowiedzialność za tworzenie części (builder).

• w builderze możesz zmienić sposób budowania części. W Twoim przypadku, Czy AddLiquid() należy dodać śmietanę lub mleko.
• w reżyserze możesz zmienić sposób montażu części. W Twoim przypadku a używając AddChocolate() zamiast AddFruits() otrzymujesz inny tort.

Jeśli chcesz tej dodatkowej elastyczności, zmieniłbym nazwę NA (ponieważ użycie baker w budowniczym sugeruje, że to zadanie budowniczych polegało na montażu części)

class LightBakingSteps : public BakingSteps {
public:
    virtual void AddLiquids()
    {
        // Add milk instead of cream
    }

    virtual void AddDryIngredients()
    {
        // Add light sugar
    }

    ...
};

class ChoclateCakeBaker : public CakeBaker {
public:
     Cake Bake(BakingSteps& steps)
     {
         steps.AddLiquieds();
         steps.AddChocolate();      // chocolate instead of fruits
         return builder.getCake();
     }
}

Odmiana GoF wzoru Builder nie ma Builder bez Director. Jest w tym inny punkt, ale wyjaśnię dalej.

Wzorzec konstruktora ma dać Ci wiele sposobów na stworzenie tego samego obiektu. Builder powinien mieć tylko metody, które budują różne części obiektu, ale algorytm-sposób wykonywania tych funkcji-powinien być problemem Dyrektora. Bez Dyrektora każdy klient musiałby dokładnie wiedzieć, w jaki sposób budynek działa. Ale z dyrektorem wszystko, co klient musi wiedzieć, to jakiego konstruktora użyć w konkretnym przypadku.

Więc mamy tu dwie części:

1. Builder, który tworzy części obiektu jeden po drugim. Ważne jest, aby pamiętać, że w tym celu zachowuje stan utworzonego obiektu.
2. Dyrektorze, który kontroluje sposób wykonania Buildera.

Teraz do punktu, o którym mówiłem wcześniej. Część Builder wzoru jest przydatna w innych przypadkach i została użyta przez różnych sprzedawców bez dyrektora do różnych celów. Przykładem takiego zastosowania może być Doctrine Query Builder.

Wadą takiego podejścia jest to, że konstruktor zaczyna budować obiekt, który staje się stateful i jeśli Klient nie resetuje konstruktora po utworzeniu obiektu - inny klient lub ten sam klient, który był używany więcej niż raz, może uzyskać części obiektu, który został utworzony wcześniej. Z tego powodu Doktryna używa Wzorzec fabryczny do tworzenia każdej instancji konstruktora.

Mam nadzieję, że to pomoże tym googlującym.

Powiedzmy, że chcesz zrobić ciasto bez suchych składników. To, co zrobisz, to dodanie nowej metody do reżysera lub mianowanie innego reżysera. To ochroni Cię przed złożonością dziedziczenia, a także sprawi, że Twój kod będzie bardziej elastyczny.

Zgadzam się z Tobą. Myślę, że innym podejściem jest to, że CakeBaker powinien mieć metodę GetCake (), która zwraca metodę cake(Klasa Cake) i MakeCake (), w której algorytm będzie działał. To dobrze, ale z drugiej strony jest tam odpowiedzialna separacja. Rozważ abstrakcyjnego budowniczego i konkretne buldery jako budowniczych części ciasta tylko i dyrektor jako kierownik lub projektant, którego zadaniem jest złożenie i wyprodukowanie ciasta.

Konstruktor wie, jak wykonać określone kroki. Reżyser wie, jak zmontować całość za pomocą kroków konstruktora.

Pracują razem.

Jedyną kruchością, jaką widzę w tym wzorze, jest to, że klient jest w stanie wywoływać metody Builder bezpośrednio bez Director - co może powodować pewne problemy i niespójność (na przykład nie wywoływanie metody Init, która jest częścią całego algorytmu)

Minusem wzorców jest to, że zanieczyszczają one nasze zrozumienie domeny biznesowej terminami technicznymi i zacierają nasze skupienie.

Jak widzę-jest zbyt wiele powiązań między ciastem a wiedzą, jak je zrobić. Można je oddzielić, wprowadzając pomysł, aby ciasto miało przepis w naszym kodzie (bardziej jak zapożyczenie z realnego świata, zaprojektowanie naszego modelu według domeny biznesowej). Przepis miałby składniki i etapy pieczenia (tylko nazwę kroku, a nie rzeczywistą realizację, ponieważ przepisy nie piecz ciast) jak zrobić ciasto co opisuje przepis. Nasz piekarz miałby metodę BakeCake( przepis) i kilka mniejszych metod zgodnie z krokami pieczenia, takich jak wymieszanie, dodanie składnika itp.

Pamiętaj, że jeśli będziesz musiał ogólnie modelować szefa kuchni, a nie tylko piekarza tortów, musisz również oddzielić wiedzę o robieniu wypieków od samego piekarza. Można to zrobić poprzez wprowadzenie idei kucharza posiadającego umiejętności.