Dekorator wzorzec projektowy - czy jest konieczny w moim schemacie?

0

Hej, zaczynam uczyć się wzorców projektowych i mam pytanie czy klasa Dekorator jest konieczna w tym schemacie czy jest tylko aby polepszyć wizualizację działania? I jesli tak to co powinno się w niej znajdować. Napisałem przykładowy program i chyba działa jak powinien ale gdy pominę klase Dekorator a klasy Klimatyzacja i Opony_Zimowe będą dziedziczyć z klasy Samochód w której znajdują się wirtualne funkcje więc po co klasa Dekorator?
z góry dzięki

decorator.jpg

dodanie obrazka do załączników i treści posta - @furious programming

0

Dlaczego Klimatyzacja miałaby dziedziczyć po klasie Samochód ? Klimatyzacja jest samochodem ? To pytanie powinno Ci pomóc.

0

Odpowiedzią jest że nie powinna bo klimatyzacja nie jest szczególnym rodzajem samochodu ale dekorator też chyba nie jest szczególnym rodzajem samochodu więc dlaczego on dziedziczy po samochodzie?

1

Dekorator dziedziczy po samochodzie tylko i wyłącznie po to, aby zachować zgodność typów. Jest w zasadzie alternatywą dla dziedziczenia.
Dorzucam jeszcze link, powinien pomóc Ci to lepiej zrozumieć: http://stackoverflow.com/questions/12379848/decorator-design-pattern-vs-inheritance

0

Nie wiem co chcesz osiągnąć, ale Dekorator po prostu nie ma sensu. Jesli już zainteresuj się Budowniczym, wnioskując po klasach może Ci się przydać.

0

Ale chodzi o to żeby obiekt klasy mercedes już istniał i żeby klimatyzację lub opony można było dodać już po stworzeniu obiektu.
Mając tylko wskaźnik do obiektu mercedes mogę wysłać ten wskaźnik jako argument dla konstruktora klasy Klimatyzacja i otrzymać nowy obiekt rozszerzony o klimatyzację

0

@tytrydsdf ale to by było totalnie bez sensu. Możesz zrobić sobie interfejs (czyli klasę z samymi metodami) Samochód i potem robić delegację zamiast dziedziczenia, ale wtedy Klimatyzacja czy OponyZimowe wcale nie dziedziczą z tego interfejsu! Masz po prostu nową klasę np. "SamochódZKlimatyzacją" który dziedziczy po tym interfejsie i wewnątrz ma pole typu Samochód, oraz pole z Klimatyzacją. Ty to po prostu źle nazwałeś.

0

ale ja nie mam zamiaru tego teraz wykorzystywać w żadnym projekcie tylko chciałem zrozumieć jak działa ten wzorzec projektowy i jesli go kiedyś będę potrzebował to żebym wiedział że coś takiego jest możliwe do zrobienia

0
tytrydsdf napisał(a):

Odpowiedzią jest że nie powinna bo klimatyzacja nie jest szczególnym rodzajem samochodu ale dekorator też chyba nie jest szczególnym rodzajem samochodu więc dlaczego on dziedziczy po samochodzie?

Dekorator dziedziczy po samochodzie po to, żebyś samochodu udekorowanego w opony zimowe albo klimatyzację, mógł użyć wszędzie tam, gdzie samochodu bez wyposażenia. Gdyby nie było takiej możliwości, nie miałoby to przecież sensu.

miszasty93 napisał(a):

Nie wiem co chcesz osiągnąć, ale Dekorator po prostu nie ma sensu. Jesli już zainteresuj się Budowniczym, wnioskując po klasach może Ci się przydać.

Jak Ci się lodówka nie podoba, to zainteresuj się warcabami?

0

To wg was co powinienem zrobić w celu zrozumienia tych wzorców? Wydaje mi się że generalnie rozumiem dziedziczenie, polimorfizm itp ale tu się teraz pojawiają nowe klasy które są odpowiedzialne tylko za obsługę metod innej klasy albo tworzenie jej nowych elementów składowych. Do tego te klasy też dziedziczą i nie ukrywam że się w tym gubię bo dochodzą jeszcze konstruktory a w nich wywołania konstruktorów klas z których dziedziczą i dużo innych rzeczy. Co powinienem dobrze umieć żeby móc przystąpić do nauki wzorców? Może powinienem nauczyć się czytać schematy w umlu bo teraz dopóki nie zobaczę gotowej implementacji to są dla mnie niezrozumiałe

0

dobrze użyłeś wzorca - problemem jest tylko nazewnictwo
klasy nie powinny się nazywać "Klimatyzacja" tylko "SamochodZKlimatyzacja" itp
po to jest klasa dekorator że każda dziedzicząca z niej klasa jest sama w sobie dekoratorem - można w konstruktorze klimatyzacji podać instancję klasy SamochodZOponamiZimowymi tym samym uzyskujac SamochodZKlimatyzacjaIOponamiZimowymi

Czy ten wzorzec jest tu konieczny? Uważam że nie - tego wzorca należy głównie używać gdy nie możemy lub nie chcemy ruszyć klasy nadrzędnej (Samochodu) - gdy projektujemy aplikację od zera rzadko znajdzie się potrzeba użycia tego wzorca

W tym przypadku klasa Samochod powinna raczej zawierać kolekcję typu (nie mylić z typem) Features i w niej wszystkie funkcjonalności. Potem w wyliczaniu ceny należałoby przelecieć po wszystkim i pododawać ceny - czas wykonania będzie podobny jak we wzorcu Dekorator tylko callstack nie będzie się wydłużał - nie będzie też problemu z usunięciem jakiejś cechy podczas działania programu; w przypadku wzorca dekorator żeby usunąć jakąś cechę należy złożyć obiekt od nowa

0

@tytrydsdf ja bym powiedział że wręcz przeciwnie. Z diagramów to czasem cieżko ogarnąć nawet takie proste rzeczy jak strategia czy kompozyt. Ja polecam po prostu zaimplementować sobie dany wzorzec i zobaczyć jak działa i co ci daje. Bo inaczej diagram będzie niezrozumiały.

0
tytrydsdf napisał(a):

To wg was co powinienem zrobić w celu zrozumienia tych wzorców?

Używać ich. Najpierw napisać sobie kod "po swojemu", następnie z użyciem wzorca i porównać.

uuuuuuuuuuuuf napisał(a):

dobrze użyłeś wzorca - problemem jest tylko nazewnictwo
klasy nie powinny się nazywać "Klimatyzacja" tylko "SamochodZKlimatyzacja" itp
po to jest klasa dekorator że każda dziedzicząca z niej klasa jest sama w sobie dekoratorem - można w konstruktorze klimatyzacji podać instancję klasy SamochodZOponamiZimowymi tym samym uzyskujac SamochodZKlimatyzacjaIOponamiZimowymi

Bazowa klasa powinna się nazywać Wyposażenie a nie Dekorator, i wszystko byłoby jasne.

W tym przypadku klasa Samochod powinna raczej zawierać kolekcję typu (nie mylić z typem) Features i w niej wszystkie funkcjonalności. Potem w wyliczaniu ceny należałoby przelecieć po wszystkim i pododawać ceny - czas wykonania będzie podobny jak we wzorcu Dekorator tylko callstack nie będzie się wydłużał - nie będzie też problemu z usunięciem jakiejś cechy podczas działania programu; w przypadku wzorca dekorator żeby usunąć jakąś cechę należy złożyć obiekt od nowa

Bardzo dobry pomysł, tylko trochę trudno się uczyć o dekoratorze nie używając go. Ale poza tym, to po prostu genialne.

0
somekind napisał(a):

Bardzo dobry pomysł, tylko trochę trudno się uczyć o dekoratorze nie używając go. Ale poza tym, to po prostu genialne.

żeby poznać wzorzec wypadałoby też się dowiedzieć kiedy danego wzorca należy użyć a kiedy raczej nie
akurat ten wzorzec wydaje mi się rzadko używany i z moich obserwacji dużo programistów nawet z wieloletnim doświadczeniem go w ogóle nie rozumie lub nigdy nie stosowało (przykładem mogą być odpowiedzi w tym temacie)

Shalom napisał(a):

@tytrydsdf ja bym powiedział że wręcz przeciwnie. Z diagramów to czasem cieżko ogarnąć nawet takie proste rzeczy jak strategia czy kompozyt

moim zdaniem kwestia obycia - UML powstał po to żeby łatwiej było zrozumieć idee - jeśli ktoś łatwiej ją rozumie z kodu to znaczy że umie lepiej programować niż czytać diagramy i ma z tym większe doświadczenie, ale to nie znaczy że diagramy są trudniejsze w zrozumieniu

ja osobiście przykładowo na logice w szkole zawsze wyrażenia tłumaczyłem sobie na wyrażenie w jakimś języku programowania bo było mi je wtedy dużo łatwiej zrozumieć ;) różny był tylko zapis, ale zamiast nauczyć się nowego zapisu wolałem używać już znanego

0

to jakich wzorców się na początku polecacie nauczyc? Zapoznałem się już ze strategią i singletonem, jakie następne?

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