Wzorzec budowniczego - czy unikać ?

0

Chodzi o to,ze w tym wzorcu wystepuje mechanizm dziedziczenia,oraz ilosc kodu drastycznie sie zwieksza poprzez deklarowanie klasy budowniczego oraz klasy kierownika.
W związku z tym pytam sie czy lepiej unikac tego wzorca i traktować go tak samo jak singleton (czyli jako antywzorzec) ?

Prosze tez o ocene implementacji wzorca budowniczego w C++.Nie jest kreatywna,wrecz mocno przerobiona z internetowego przykladu,ale nie ukryje ze jest to dla mnie koderski twardy orzech do zgryzienia na dzien dzisiejszy :P

#include <iostream>

class Computer
{
    std::string processor;
    std::string graphicCard;
    std::string memoryRAM;
    std::string hardDisc;
public:
    inline void setProcessor(std::string comProcessor){processor=comProcessor;}
    inline void setGraphicCard(std::string comGraphicCard){graphicCard=comGraphicCard;}
    inline void setMemoryRAM(std::string comMemoryRAM){memoryRAM=comMemoryRAM;}
    inline void setHardDisc(std::string comHardDisc){hardDisc=comHardDisc;}
    inline std::string getProcessor()const{return processor;}
    inline std::string getGraphicCard()const{return graphicCard;}
    inline std::string getMemoryRAM()const{return memoryRAM;}
    inline std::string getHardDisc()const{return hardDisc;}
};
///////////////////////////////////BUDOWNICZY/////////////////////////////////////////////////////////////
class Builder
{
protected:
    Computer *computer;         
public:
    inline void newComputer(){computer = new Computer();}  
    Computer getComputer()const{return *computer;}            
    virtual void buildProcessor()=0;
    virtual void buildGraphicCard()=0;
    virtual void buildMemoryRAM()=0;                                  
    virtual void builHardDisc()=0;

};

class nerdComputer: public Builder  
{
public:
    nerdComputer(): Builder(){}
    void buildProcessor(){computer->setProcessor("INTEL CELERON");}                           
    void buildGraphicCard(){computer->setGraphicCard("NVIDIA RTX 2080 TI");}
    void buildMemoryRAM(){computer->setMemoryRAM("DDR4 16GB");}
    void builHardDisc(){computer->setHardDisc("WD PURPLE 2TB");}
};
////////////////////////////////KIEROWNIK/////////////////////////////////////////////////////////////////////
class Dircetor
{
    Builder *builder;                        
public:
    inline void setBuilder(Builder *b){builder=b;}  
    Computer getComputer(){return builder->getComputer();} 
    void make(){
        builder->newComputer();
        builder->buildProcessor();
        builder->buildGraphicCard();                                
        builder->buildMemoryRAM();
        builder->builHardDisc();
        }
};
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
int main()
{
    Dircetor *chef = new Dircetor();                        
    Builder *builder = new nerdComputer();            

    std::cout<<"PODZESPOLY KOMPUTEROWE\n";
    std::cout<<"===================="<<'\n';
    chef->setBuilder(builder);                                
    chef->make();                                                 
    Computer simpleComputer = chef->getComputer();   
    std::cout<<simpleComputer.getProcessor()<<'\n';
    std::cout<<simpleComputer.getHardDisc()<<'\n';
    std::cout<<simpleComputer.getGraphicCard()<<'\n';
    std::cout<<simpleComputer.getMemoryRAM()<<'\n';
    std::cout<<simpleComputer.getHardDisc()<<std::endl;

    return 0;
}

I szybkie pytanie - czy uzywanie getterów i setterów (metody get i set) w deklaracji klasy to dobra praktyka ? To moj sposob na modyfikowanie cech obiektu bez naruszania zasad hermetyzacji : P

3
  1. Z seterami to ostrożnie, tzreba mocno się zastanowić, czy w każdy przypadku / każdy w klasie jest potrzebny, czy nie wystarczy ustawienie pól w konstruktorze. W C++ styl 'immutable' nie jest może bardzo modny, ale jest cenny.
    Czy modyfikowanie jest potrzebne? Do namysłu.

  2. Wzorzec Budowniczy IMHO ma sens, gdy obiekt jest niezmienniczy (immutable). Gdy są setery właściwie (moje zdaniem) traci sens.
    Ma sens gdy:

  • obiekt po utworzeniu będzie niezmienniczy
  • dopuszczamy różne "komplety" wypełnienia pól (gdyby był tylko jeden "słuszny" zestaw, wystarczyłby publiczny argumentowy konstruktor.
  1. Co do formalności, ja uznaję z lepszą składnię w tej samej klasie
Computer v = Computer.builder().procesor("i5xxx").ram(16).build();

Kod, który dałaś wygląda koszmarnie, skąd to pochodzi? Nie ma NIC WSPÓLNEGO z głębokim sensem wzorca. Kierownika widzę pierwszy raz w życiu.

0

http://www.algorytm.org/wzorce-projektowe/budowniczy-builder/builder-1-c.html

Będę wdzięczna za podanie lepszej implementacji

0
AnyKtokolwiek napisał(a):

Kierownika widzę pierwszy raz w życiu.

Kierownik pochodzi z oryginalnej implementacji z Bandy Czworga. Kiedyś słyszałem opinie że pod nazwą budowniczy kryją się trzy różne wzorce (jeden z kierownikiem, jeden bez, i jeszcze jakiś inny)

0
Quanti994 napisał(a):

http://www.algorytm.org/wzorce-projektowe/budowniczy-builder/builder-1-c.html

Nie pierwszy, nie ostatni przykład, jak kiepskie są/bywają kursy internetowe, i jak subtelnie uczą źle. Chore.

Na marginesie, moja "ukochana" realizacja show() z hardkodowanycm cout

Będę wdzięczna za podanie lepszej implementacji

Dopasuj sobie do tego jednolinijkowca, taki reverse design.
Konstruktor Computera prywatny,

0
KamilAdam napisał(a):
AnyKtokolwiek napisał(a):

Kierownika widzę pierwszy raz w życiu.

Kierownik pochodzi z oryginalnej implementacji z Bandy Czworga. Kiedyś słyszałem opinie że pod nazwą budowniczy kryją się trzy różne wzorce (jeden z kierownikiem, jeden bez, i jeszcze jakiś inny)

Dzięki za info.

Dziś inaczej brzmią słowa "banda czworga". Młodzi pewnie nie pamiętają, to ówcześnie było z polityki ChRL, i było oczywiście w tamtych czasach żartem.
Dziś - podkreślę nie jest to ich wina, tylko wyznawców / naśladowców / pożal się boże edukatorów - mi dziś się już kojarzy z sekciarstwem. Mówię o czysto fonetycznym brzemieniu, i wynaturzeniach zw z wzorcami.

3

Niestety, dużo jest w internecie treści o ujemnej jakości. Teraz na taką trafiłaś.

Osobiście nie widzę za bardzo sensu w tym wzorcu tak przedstawionym (wygląda jak na mniej przyjazny w użyciu wzorzec factory), ale już wcześniej wymieniona wersja z budowaniem łańcuchowym wydaje się całkiem ciekawa:

class PersonBuilder;

class Person
{
public:
    Person(std::string const& name, int year_born):
        name_(name), year_born_(year_born)
    {
    }

    static PersonBuilder build();

    auto const& name() const { return name_; }
    auto const& year_born() const { return year_born_; }
private:
    std::string name_;
    int year_born_;
};

class PersonBuilder
{
public:
    PersonBuilder() = default;
    PersonBuilder(PersonBuilder const&) = delete;
    PersonBuilder(PersonBuilder&&) = delete;
    PersonBuilder& operator=(PersonBuilder const&) = delete;
    PersonBuilder& operator=(PersonBuilder &&) = delete;

    PersonBuilder& withName(std::string const& n) {
        name = n;
        return *this;
    }

    PersonBuilder& withYearBorn(int y) {
        year_born = y;
        return *this;
    }

    Person finalize() {
        if(!name || !year_born) {
            throw std::runtime_error("Missing fields");
        } else {
            return { *name, *year_born };
        }
    }

private:
    std::optional<std::string> name;
    std::optional<int> year_born;
};

PersonBuilder Person::build() { return {}; }

auto main() -> int
{
    auto p = Person::build()
        .withName("Jan")
        .withYearBorn(1950)
        .finalize();

    DBG(p.name());
    DBG(p.year_born());
}

https://wandbox.org/permlink/knivYa7rKauPph7y
Zalety:

  • możesz wymusić poprawność wszystkich parametrów
  • niezła czytelność, dzięki zachowaniu nazw parametrów bezpośrednio obok ich użycia
  • pozwala za jednym zamachem budować obiekty z rzadko ustawianymi opcjami bez rozwalania API klasy (np. algorym Nagle'a dla socketu TCP)
  • duży i nieczytelny konstruktor może być prywatny

Pomimo powyższego, imo to raczej przerost formy nad treścią.

3

Pomimo powyższego, imo to raczej przerost formy nad treścią.

Siła tego wzorca jest widoczna kiedy:

  • pól jest dużo
  • jest dużo pól opcjonalnych (!)

Jak masz mało pól albo wszystkie są wymagane, to nie ma za bardzo sensu. Jak masz pola opcjonalna to nagle opcja z konstruktorem sie komplikuje, bo jest ich wykładniczo dużo :) I nagle tworzenie obiektów immutable staje się bardzo trudne. Builder rozwiązuje to dość elegancko.

Taki Fluent-Builder jaki pokazał @kq to moim zdaniem jedyna sensowna implementacja.

2

Przydaje się do testów, np. jeśli w obiekcie ogólnie wymagane są wartości dla pól, ale w konkretnym teście chcemy sprawdzić coś dla tylko kilku z nich, to taki builder na potrzeby testów może wylosować wartości dla wszystkich wymaganych, a do tego dostarczy API, którym ustawimy te, których potrzebujemy. Znacząco skraca to kod związany z aranżacją testu.

0

Czy ta implementacja jest ok ?
https://cpppatterns.com/patterns/builder.html

Bo ta podana przez @kq na dzień dzisiejszy nie jest dla mnie zrozumiała ; D

1
Quanti994 napisał(a):

Czy ta implementacja jest ok ?
https://cpppatterns.com/patterns/builder.html

Na 100% publicznej klasie? Jest bez sensu.
Dlaczego jest na publicznej klasie?

  • autor dzień wcześniej przeczytał o tym wzorcu i już jest ekspertem
  • bo nie zna możliwości języka
  • obie przyczyny

Z uporem maniaku powtórzę, że istotą "ładnego" buildera jest metoda statyczna w głównej klasie, i nie szokowanie usera dodatkową klasą.

Bo ta podana przez @kq na dzień dzisiejszy nie jest dla mnie zrozumiała ; D

Z Euklidesem związane są dwie anegdoty. Według jednej z nich król Ptolemeusz I przeglądając "Elementy" zapytał autora, czy nie ma krótszych dróg wiodących do geometrii, na co Euklides odrzekł: "W geometrii nie ma nawet specjalnych dróg dla królów".

0

To w sumie ciekawe, bo te implementacje są bardzo zbliżone i ciężko mi się domyślić co jest w jednej zrozumiałego a w drugiej nie.

Jako przykład imo jest ok. Faktycznie builder nie ma sensu za bardzo jak pola są publiczne i nie ma znaczącej liczby pól opcjonalnych, ale przykład to przykład.

7

Jeśli ktoś ma problem ze zrozumieniem buildera to jest proste ćwiczenie: zrób klasę, której obiekty są immutable (czyli po stworzeniu obiektu nie da się już zmienić wartości jego pól), która ma np. 10 pól i jednocześnie wszystkie są opcjonalne (tzn. mogą być ustawione, ale nie muszą). Te wymagania oznaczają że:

  • publiczne pola odpadają
  • settery odpadają

Powodzenia!

1 użytkowników online, w tym zalogowanych: 0, gości: 1