Builder (Budowniczy)

Builder – kreacyjny wzorzec projektowy, który oddziela reprezentację obiektu od jego tworzenia, przez co możemy uzyskać różne reprezentacje jako wynik tego samego procesu.

Przeznaczenie i warunki stosowania

• Proces konstrukcji musi dawać możliwość stworzenia różnych reprezentacji tworzonego obiektu.
• Składniki obiektu i sposób ich łączenia powinien być niezależny od algorytmu tworzenia obiektu złożonego.

Builder a inne wzorce

Przypomina Fabrykę Abstrakcyjną, też służy do tworzenia obiektów złożonych. Z tą różnicą, że Abstract Factory udostępnia produkt natychmiast, a Builder tworzy go krok po kroku i zwraca dopiero w ostatnim kroku.

Budowniczy często służy do tworzenia Kompozytów.

Życiowa Analogia

Weźmy za przykład, że planujesz remont kuchni. Zatrudniasz kierownika robót (Director), przekazujesz mu wymagania i oczekiwania co do efektu końcowego (Produkt). Dyrektor może współpracować z dwiema ekipami (Builders), jedna wykona remont tanimi materiałami, a druga w jakości premium.
Każda ekipa remontowa (Builder) może dostarczyć Tobie wyremontowaną Kuchnię (Produkt). Ty (Klient), „dostarczasz” jedynie ekipę (Builder) oraz wymagania kierownikowi (Director), który zajmuje się remontem krok po kroku, dostarczając Tobie wyremontowaną kuchnię (Produkt).

Builder Struktura

• Builder – Budowniczy
  • określa interfejs do tworzenia składników obiektu – wyniku: Product
• ConcreteBuilder – Budowniczy Konkretny
  • udostępnia interfejs do pobierania produktów `GetResult()`
  • tworzy i łączy składniki produktu w implementacji klasy Builder
  • definiuje i śledzi wygenerowane reprezentacje
• Director – Kierownik
  • za pomocą interfejsu klasy Builder tworzy obiekt – Product
• Product – Produkt
  • generowany obiekt złożony, obejmuje klasy definiujące składowe elementy

Builder Konsekwencje Stosowania

Pozytywne:

• Odizolowanie reprezentacji od kodu służącego do tworzenia produktu – klient nie potrzebuje żadnych informacji o klasach definiujących wewnętrzną strukturę produktu

• Lepsza kontrola nad procesem tworzenia jak i wewnętrzną strukturą produktu – produkt odbierany jest dopiero po jego ukończeniu. tworzenie odbywa się krok po kroku, w przeciwieństwie do innych wzorców konstrukcyjnych tworzących produkt w jednym etapie

• Możliwość modyfikacji wewnętrznej reprezentacji produktu – przez zdefiniowanie nowego rodzaju obiektu Builder. Który to obiekt ukrywa reprezentację, sposób składania i strukturę produktu, a tworzenie produktu odbywa się dzięki abstrakcyjnemu interfejsowi udostępnionym obiektowi Director (`BuildPart()`)

Negatywne

Przy prawidłowym stosowaniu nie stwierdzono 🙂 Jak każdy wzorzec wciśnięty w rozwiązanie „na siłę” może pogorszyć czytelność kodu i jego utrzymanie.

Builder Implementacja

W głównych punktach, implementacja wzorca Builder, opiera się o:

• Director – Kierownik – w prezentowanym przykładzie Program.cs
• Product – Produkt – buildedHost
• Builder – Budowniczy – builder
• ConcreteBuilder – Budowniczy Konkretny – builder – web host builder zwrócony przez CreateDefaultBuilder() (Budowniczy dostarczony do Kierownika)
  • w zależności od budowniczego konkretnego, takie same ustawienia, mogą przynieść inny rezultat (Produkt) – patrz analogia życiowa

Dyrektor definiuje kolejności wykonywania kroków budowania, podczas gdy Budowniczy dostarcza implementacje tych kroków. Dyrektor ukrywa szczegóły tworzenia produktu przed klientem, wykonuje poszczególne kroki niezbędne do dostarczenia produktu oraz dostarcza rezultat – produkt. Klient musi tylko połączyć Budowniczego z Dyrektorem.

Powyższy przykład, to Budowniczy do stworzenia i uruchomienia prostej aplikacji web. W klasie Startup.cs (nie będącej stricte częścią wzorca) zawarte są dwie metody, które są wywoływane w czasie budowania Produktu – ConfigureServices oraz Configure – poprawiają czytelność i przejrzystość kodu, a także podąża za SOLID’em – zasadą jednej odpowiedzialności (Program – Dyrektor, zarządza tworzeniem obiektu, Startup – podstawowa konfiguracja Produktu). Metody te mogą być również wywołane bezpośrednio (patrz komentarz //webBuilder.ConfigureServices(...))

Możesz spróbować sam/a, tworząc nowy projekt ASP.NET Web Application.

Podsumowanie

Niewątpliwie Budowniczy jest bardziej zaawansowanym wzorcem projektowym. Pozwala na szczegółową konfigurację oczekiwanego rezultatu oraz dodatkowe walidacje danych. Oddziela reprezentację obiektu od jego tworzenia, przez co możemy uzyskać różne reprezentacje jako wynik tego samego procesu.

Ważne abyś samemu zastanowił się i przemyślał, czy Budowniczy to wzorzec projektowy który pasuje do Twojego problemu, czy może inny Wzorzec Projektowy byłby lepszy, a może prosty kod będzie wystarczający? Znajomość wzorców z pewnością pomoże Tobie w tych przemyśleniach.

Zainteresował Cię materiał? Zapraszam do listy mailowej, by być na bieżąco z kolejnymi wpisami.