Nie rozumiem wzorców projektowych programowania


16

Pracuję z javascript przez ostatnie 4 lata. Jestem bardzo pewny swoich umiejętności rozwiązywania problemów i widzę, że poprawia się jakość mojego kodu. Staram się być na bieżąco ze społecznością i obecnie pracuję z ES2015 i React.js. Wydaje mi się jednak, że nie jestem w stanie pojąć wzorców programowania. Wiem, gdzie znaleźć zasoby na ten temat i już czytałem o tym książki. Przy podejmowaniu decyzji dotyczących struktury projektu polegam na moich starszych współpracownikach, ale nie mam z tym problemu.

Ilekroć muszę coś zacząć sam, szukam tych dwóch ścieżek: Jeśli używam dużej biblioteki / frameworka, takiego jak React.js, mam tendencję do kopiowania tego, co robi społeczność; Jeśli jestem na czymś mniejszym, będę używał wzoru modułu. Wiem, że kiedy lepiej zrozumiem ten temat, będę mógł podejmować lepsze decyzje, ale na razie jestem całkowicie zagubiony.

Czy powinienem poszukać wyższego wykształcenia w tym zakresie? Czy potrzebuję mentora na ten temat? Czy jestem po prostu głupi? Czy to naprawdę tak trudne do zrozumienia?


6
Moim zdaniem niektóre języki są bardziej „wybaczające” niż inne, jeśli chodzi o konieczność stosowania wzorców projektowych. Języki kompilowane na silnie typowane języki (takie jak Java i C #) są bardziej dotknięte złym projektem niż słabo typowane języki skryptowe, takie jak JavaScript i PHP. Oczywiście, wzorce projektowe nie są przydatne w obu przypadkach.
Matthew

3
Ważną rolę odgrywa również rozmiar projektu.
Matthew

2
@Nathew nitpick Niekoniecznie nazwałbym Java / C # silnie wpisanym ...
Jared Smith

2
@JaredSmith prawda, często zapominam o rozróżnieniu między silnym i statycznym pisaniem.
Matthew

6
Jeśli próbujesz wcielać w życie i ogólnie wzorce , Przestań! Nic tam nie ma! Wzór jest popularnym rozwiązaniem często występującego problemu i ktoś nadał mu nazwę. To wszystko. Może ci być trudno uchwycić jakiś konkretny wzorzec - ja sam nie mogę sobie przypomnieć, jak skutecznie użyć wzorca „gość” do naśladowania podwójnej wysyłki w Javie - Ale jeśli szukasz tajnego sosu, który łączy „gościa” powiedz „obiekt przesyłania danych”, nie znajdziesz go. To tylko dwa popularne rozwiązania dwóch typowych problemów, ktoś nadał im nazwy, a nazwy utknęły.
Solomon Slow

Odpowiedzi:


34

Wzorce projektowania oprogramowania są dobrze znanymi rozwiązaniami znanych problemów. Sposób, w jaki je rozumiesz, polega na uczeniu się wzorców, zrozumieniu ich działania i wiedzeniu, kiedy należy zastosować każdy z nich do projektu oprogramowania.

Sposób uczenia się wzorców projektowych polega na ich analizowaniu, pojedynczo. To ciągły proces edukacji. Jeśli chcesz zmniejszyć ślad uczenia się, przestudiuj wzorce, które odnoszą się bezpośrednio do aktualnie używanych technologii.

Kilka ważnych rzeczy na temat wzorców projektowych:

  1. Niektóre wzory mają charakter architektoniczny. MVC i MVVM są przykładami takich wzorców. Stosujesz takie wzorce, gdy potrzebujesz związanych z nimi korzyści organizacyjnych i strukturalnych.

  2. Niektóre wzorce projektowe są obejściem braków w językach programowania. Nie potrzebujesz tych wzorów, jeśli używasz bardziej ekspresyjnego języka programowania, ale często nie możesz dokonać tego wyboru. Większość wzorców GoF należy do tej kategorii .

  3. Użyj wzorca oprogramowania tylko wtedy, gdy próbujesz rozwiązać problem, który wzorzec jest specjalnie zaprojektowany do rozwiązania. Jeśli piszesz aplikację, łącząc wzory oprogramowania, robisz to źle.

  4. Nie istnieje żaden wzorzec oprogramowania dla każdego istniejącego problemu komputerowego. W takim przypadku programowanie byłoby jedynie ćwiczeniem polegającym na dopasowaniu wzorców.

  5. Niektóre wzory są w rzeczywistości anty-wzorami. Dodatkowa złożoność, którą wprowadzają te wzorce, przewyższa korzyści, które zapewniają. Będziesz musiał sam zdecydować, na podstawie wzoru, który z tych wzorów unikniesz.


Dobra odpowiedź, chociaż nie zgodziłbym się ze stwierdzeniem, że większość wzorców GoF jest obejściem braków w językach programowania. Często niektóre wzorce lepiej nadają się do niektórych języków, tak, ponieważ języki zwykle są projektowane z myślą o określonych problemach i rozwiązaniach.
Polygnome,

1
Wzory Gof mają 20 lat. Większość z nich została stworzona, aby naprawić problemy z C ++, problemy odziedziczone przez Javę, ponieważ Java jest oparta na C ++.
Robert Harvey,

Paradoksem w tej odpowiedzi jest część „dobrze znanego problemu”. Trudno zrozumieć te „dobrze znane problemy”, jeśli nigdy ich nie doświadczyłeś.
Fuhrmanator,

2
Java nie jest oparta na C ++. Składnia javas jest inspirowana przez C ++, ale z pewnością nie jest na niej oparta. oba języki działają całkiem inaczej. Z faktu, że sprzęt Java powstrzymuje się od samodzielnego zarządzania pamięcią, ponieważ nie ma szablonów, ale raczej
ogólne

4

Podejście każdego do uczenia się jest trochę inne i nie mam pojęcia, jakie jest twoje ogólne podejście, ale wierzę, że wyrządziłeś sobie krzywdę, oznaczając siebie jako „głupiego”.

Osobiście z moich obserwacji tego, co wielu nazwałoby „odnoszącymi sukcesy” inżynierami, projektantami itp., Wszyscy mają wspólny motyw do nauki: „doświadczenie”. Wierzę, że jest to twoja „wyższa edukacja” i nauczysz się z niej szybciej niż kupowanie ton książek w Amazon i czytanie ich (mój zły nawyk).

Na przykład weź wzorzec GOF, taki jak wzorzec poleceń, i zaimplementuj go w wybranym języku. Dowiedz się, jakie korzyści to daje i jakie wady. Różne książki na temat wzorców projektowych wyjaśnią ci to, ale uważam, że lepiej jest zastosować tę wiedzę praktycznie i wyciągać z niej wnioski. Nie lekceważ materiałów do czytania, mają one swój cel, ale świat IT nie jest ćwiczeniem podręcznika. To powiedziawszy, to moja opinia i pogląd na świat IT, a częściowo stanowi własną walkę na początku mojej kariery w inżynierii oprogramowania. Poważnym problemem, jaki widzę, nawet w przypadku bardzo doświadczonych programistów, jest niecierpliwość i zapominanie o czerpaniu radości z tego, co robią. Więc nie spiesz się z tym, czego się uczysz i pamiętaj, aby naprawdę czerpać radość z tego, co robisz, w przeciwnym razie po co męczyć się w to, aby w to inwestować?

Ponadto skorzystaj z praktycznego doświadczenia innych osób. Istnieje mnóstwo rozwiązań typu open source, zarówno złych, jak i dobrych, i można się z nich uczyć. Spójrz, jak zastosowali wzorce i zastanów się, jak inaczej byś sobie z tym poradził.

Tak więc, moja ogólna rada jest taka, że ​​jeśli uważasz, że twoje podejście jest złe, zmień je. Spójrz na ludzi wokół ciebie, którzy czują, że uczą się materiału, który według ciebie nie chwytasz, i spójrz na to, co robią, a nawet zapytaj ich.


1
Naprawdę uważam, że programowanie jest jak gra w szachy. Możesz mieć w sobie trochę rodzimych talentów, możesz grać przez cały dzień, ale jeśli nie czytasz książek o szachach, nie możesz robić postępów, a co ważniejsze, nie doceniasz piękna tej gry.
Adrian Iftode,

@AdrianIftode - uzgodniono. Jak wspomniano, nie dyskontowałem książek, blogów ani innych materiałów do czytania, ale jest to powszechny problem, który znalazłem u ludzi, którzy dążą do opanowania języka programowania / platformy / frameworku itp. I najwyraźniej zrobili mało kodowania lub wysiłek, ale przeczytałem każdą książkę, w której można potrząsnąć kijem.
Desolate Planet,

@AdrianIftode Cóż, nie do końca. Grając w szachy bez czytania książek, nadal możesz wiele się dowiedzieć o grze. Jedyna różnica polega na tym, że nie uczysz się tak szybko, jak to możliwe, czerpiąc z doświadczeń i myśli chessmastersów. Z drugiej strony, myśląc o pewnych rzeczach, możesz natknąć się na rozwiązanie lub dwa, które zostały całkowicie przeoczone przez ludzi, którzy uczą się tylko od chessmasterów i które możesz wykorzystać na swoją korzyść. Ostatecznie uważam, że połączenie obu rodzajów uczenia się zapewnia najlepszą korzyść. W szachach, a także w programowaniu.
cmaster

1

Krótka odpowiedź brzmi: nie potrzebujesz ich. Możesz pisać kod bez nich. Jak powiedział Matthew w komentarzach, jest to szczególnie prawdziwe w JavaScript, gdzie język jest dość elastyczny, a projekty są zwykle mniejsze. Ale jeśli programujesz od 4 lat, trudno mi uwierzyć, że nie natknąłeś się na rzeczy, które wydają się powtarzalne lub niezręczne. To te obszary, które albo odkrywacie na nowo, albo brakuje wzorców projektowych.

Przykład: system zdarzeń JavaScript jest często nieodpowiedni do danego zadania. Czy nigdy nie chciałeś łączyć lub przekształcać strumieni wydarzeń? Czy ta seria wydarzeń była sama w sobie pierwszorzędnymi wartościami? Potrzebujesz wzorów Mediatora i / lub Obserwatora. Potrzebujesz dwukierunkowego powiązania danych? Ta sama historia

Czy kruchość hierarchii prototypów spadła? Wzory Mixin / Trait / Subclass Factory na ratunek.


4
Praktycznie niemożliwe jest napisanie jakiegokolwiek nietrywialnego programu bez użycia wzorców projektowych, zwykle będziesz również używać wielu popularnych. To, czego nie potrzebujesz, to móc rozpoznać wzorce, których używasz po imieniu. Możesz pisać działający kod, nawet jeśli nie możesz nazwać wszystkich wzorców projektowych używanych w całym kodzie.
Servy,

@Servy Wzory projektowe są abstrakcjami, abstrakcje nie są absolutnie konieczne. Zawsze możesz napisać ad hoc jednorazową implementację podstawowych zachowań ... raz po raz i jeszcze raz i jeszcze raz. Na przykład w podanym przeze mnie przykładzie dotyczącym wydarzeń można ręcznie połączyć wszystkie zainteresowane strony, a następnie zmienić je za każdym razem, gdy zmieniają się wymagania, jest to po prostu do kitu w porównaniu do używania pub / sub. W przypadku podklas możliwe jest (jeśli jest to marnotrawstwo) ręczne kodowanie w każdej możliwej sytuacji za pomocą szeregu jednorazowych klas - po prostu nie jest tak dobre.
Jared Smith,

1
Wzory projektowe mogą być bardzo szerokie. Często szersze wzorce projektowe są tak oczywiste, że nawet nie uważamy ich za wzorce projektowe (szczególnie, gdy mają one specjalne wsparcie językowe). Pętla to wzór projektowy. Funkcje są wzorcem projektowym. Obiekty są wzorem.
Servy,

@Servy, jeśli tak używasz tego terminu, to nie zgadzam się, ale mam wrażenie, że OP konkretnie oznaczało wzorce GOFish.
Jared Smith,

1
@JaredSmith Wzory projektowe nie są abstrakcjami. Nawet jeśli wdrażasz je wielokrotnie w celu rozwiązania konkretnego problemu, nadal są wzorami . Nie musisz pisać ogólnej klasy Observer i używać jej do używania wzorca Observer . Pisanie konkretnych obserwatorów i konkretnych metod rejestracji i powiadamiania ich nadal używa wzorca. trudną rzeczą jest rozpoznanie wzoru. Czasami używasz wzoru, nawet nie znając jego nazwy,
Polygnome,

1

Znajdź mentora, kogoś z bardzo dobrym doświadczeniem do nauki. Zadaj mu pytanie, obejrzyj jego kod, prześlij recenzję kodu i spróbuj z nim współpracować. To najlepszy sposób na zwiększenie umiejętności kodowania.

dodatkowy:

  • Współpracuj przy prostym projekcie OSS, który Ci się podoba

  • Jeśli istnieją dwa sposoby rozwiązania tego samego problemu, zawsze wybieraj prostsze

  • Zdobądź dodatkowe doświadczenie z pobocznymi projektami, w których możesz popełniać wszelkiego rodzaju dziwne błędy, a nauczysz się wzoru projektowego „na poważnie” (tm)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.