Wzorzec builder jako ominięcie konieczności tworzenia konstruktorów destruktorów operatorów itp

0

Cześć.
Ostatnio sporo tworzę na stosie obiektów. Tak sobie założyłem. Jest to miejscami upierdliwe, ale dopuszczam, że coś robie nie do końca tak jak robić się powinno.
Problem: implementacja konstrkuktora często wumusza konstruktory kopiujące i operatory przypisania. Troche mnie to irytuje, bo trzeba dużo pisać :) Wymyśliłem sobie, że zamiast używania konstruktorów z argumentami napiszę statyczną metodę np make, która mi taki obiekt buduje, ale robi to tak:

static Klasa make(int param1, int param2) {
    Klasa tmpRes;
    tmpRes.setDefault();//czysci pola jeśli jest ich dużo
    tmpRes.pole1 = param1;
    tmpRes.pole2 = param2;
    //czasem sie posiłkuje poniższym polem
    tmpRes.valid = true;
}

No i takie coś można spokojnie wrzucać do wektorów, parsowac parserami itd. Bez tego musiałbym napisać konstruktor, konstruktor kopiujący, operator przypisania. Przynajmniej te trzy.

Pytanie: czy to co napisałem jest dobrym kirunkiem czy herezją? Dajcie pls jakiegoś hinta, podzielcie sie doświadczeniem. Pytam, bo chciałbym posiąść tą wiedzę na skróty. Zanim przeczytam wszystkie dostępne info o wzorcach konstrukcyjnych itd.

5

metody-fabryki to nie jest nic nowego, tylko szczerze mówiąc w tym przypadku nie widzę żadnej zalety nad konstruktorem. A jeśli chodzi o operator= itd, używaj rule of zero.

0
pawel_nowy_tu napisał(a):

Pytam, bo chciałbym posiąść tą wiedzę na skróty. Zanim przeczytam wszystkie dostępne info o wzorcach konstrukcyjnych itd.

Nie powiem ciekawe założenie. Wiedza na skróty? Zastanów się czy chciałbyś pójść do lekarza który tak samo jak Ty posiadł wiedzę na skróty. Takie coś wcześniej czy później odbije się czkawką. Pytanie kiedy, czy wcześniej, czy już później, jak będziesz pisał kod który pójdzie na produkcję i zrobi wielkie bum w najmniej odpowiednim momencie powodując straty w realnej gotówce i to czasem niemałej... :]

0
Mr.YaHooo napisał(a):
pawel_nowy_tu napisał(a):

Pytam, bo chciałbym posiąść tą wiedzę na skróty. Zanim przeczytam wszystkie dostępne info o wzorcach konstrukcyjnych itd.

Nie powiem ciekawe założenie. Wiedza na skróty? Zastanów się czy chciałbyś pójść do lekarza który tak samo jak Ty posiadł wiedzę na skróty. Takie coś wcześniej czy później odbije się czkawką. Pytanie kiedy, czy wcześniej, czy już później, jak będziesz pisał kod który pójdzie na produkcję i zrobi wielkie bum w najmniej odpowiednim momencie powodując straty w realnej gotówce i to czasem niemałej... :]

Troche przesada. Między pójściem na skróty a pójściem na łatwizne jest różnica. Patrząc w ten sposób każda ksiażka pt. receptury, 50 najlepszych praktyk itd to zło. A przeciez ja nie szukam nic innego. poza tym nie można być od razu super pro, a pisać trzeba. Ktoś mnie przetestował, zatrudnił, płaci mi n a nie n+1 to ma zadaną jakosć gdzie jakość to parametr ;)

2

Po części tak jest, że książki typu "50 sposobów na coś tam" są złe. Przeważnie uczą one gotowych rozwiązań, a nie dochodzenia do rozwiązania i niezbyt wyjaśniają tematykę. Nie wiem jak inni, ale ja osobiście nie lubię jak ktoś stosuje podane rozwiązania ślepo "bo tak kazali". To nie jest programista, a po prostu zwykły klepacz, a przecież nie o to chodzi żeby być zwykłym klepaczem :) A może wynika to z moich złych doświadczeń podczas pracy z takimi osobnikami...

0

Zawsze można użyć default przy deklaracji konstruktorów czy operatorów przypisania.

0

Modern C++ Features – Default Initializers for Member Variables
Non-static data members # Member initialization

dodatkowo jak wyżej default/delete

Jeszcze luknij na std::tuple, std::make_tuple

i różne w google w stylu "struct vs tuple"

0
pawel_nowy_tu napisał(a):

Cześć.
Ostatnio sporo tworzę na stosie obiektów. Tak sobie założyłem. Jest to miejscami upierdliwe, ale dopuszczam, że coś robie nie do końca tak jak robić się powinno.
Problem: implementacja konstrkuktora często wumusza konstruktory kopiujące i operatory przypisania. Troche mnie to irytuje, bo trzeba dużo pisać :) Wymyśliłem sobie, że zamiast używania konstruktorów z argumentami napiszę statyczną metodę np make, która mi taki obiekt buduje, ale robi to tak:

static Klasa make(int param1, int param2) {
    Klasa tmpRes;
    tmpRes.setDefault();//czysci pola jeśli jest ich dużo
    tmpRes.pole1 = param1;
    tmpRes.pole2 = param2;
    //czasem sie posiłkuje poniższym polem
    tmpRes.valid = true;
}

No i takie coś można spokojnie wrzucać do wektorów, parsowac parserami itd. Bez tego musiałbym napisać konstruktor, konstruktor kopiujący, operator przypisania. Przynajmniej te trzy.

Pytanie: czy to co napisałem jest dobrym kirunkiem czy herezją? Dajcie pls jakiegoś hinta, podzielcie sie doświadczeniem. Pytam, bo chciałbym posiąść tą wiedzę na skróty. Zanim przeczytam wszystkie dostępne info o wzorcach konstrukcyjnych itd.

tmpRes.setDefault();
To jest koronny dowód, że JUŻ WŁOŻYŁEŚ tam jakąś pracę. MSZ lepiej by poszła na napisanie konstruktora.

Podstawą wzorców jak builder, czy też kontekstem, jest "jakaś" dynamika klasy, np uniemożliwienie modyfikacji PO utworzeniu. Słówko "niezmienniczość obiektu" / "immutable" w świecie C++ nie ejst może nagłośnione tak jak w Javie/C#, ale to są "te sprawy". Nie zawsze to da sie idealnie zrobic w C++, ale warto oswoić się, i to o wiele wcześniej, niż jak mówisz "czytanie o wzorcach projektowych"

To NIE JEST zamiast konstruktora.
Twoja idea i realizacja niosą wiele, wiele problemów, zgadzam się z kolegami.

No i takie coś można spokojnie ... parsowac parserami itd.

Sugeruję, może źle wybrałeś język. To "parsowanie" ma zupełnie inne możliwości w językach z refleksją.

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