Co to jest programowanie oparte na wzorcach?

Czy ktoś może wyjaśnić obsesję na punkcie wzorców i anty-wzorców w programowaniu? Pytam, ponieważ absolutnie nie mam pojęcia, co oznaczają te wzory. W obliczu zadania programistycznego przez chwilę myślę o tym problemie, zapisz niektóre struktury danych, które moim zdaniem będą odpowiednie, prototypuj rozwiązanie, rozdziel niektóre moduły i iteruj. Nigdzie nie sądzę, że „Och, potrzebuję tutaj wzoru FunkyLookyTastic”.

Wzór jest powszechnym podejściem do rozwiązywania typowego problemu; nic więcej i nic mniej. Znając je i rozumiejąc, możesz skorzystać z doświadczeń innych ludzi, aby poprowadzić Cię w kierunku rozwiązania, które okazało się skuteczne, uniknąć pułapek napotkanych w przeszłości i omówić rozwiązanie przy użyciu terminologii znanej innym, którzy znać ten wzór.

Oczywiście możesz wymyślić dobre rozwiązanie bez wyraźnego użycia wzorca, a równie dobrze wymyślić złe rozwiązanie, próbując zastosować wzór, który tak naprawdę nie pasuje do konkretnego problemu. Myślę, że obserwowana przez ciebie „obsesja” na ogół pochodzi od ludzi, którzy właśnie odkryli tę koncepcję, i uważam, że ma ona większą moc niż jest w rzeczywistości. Większość ludzi szybko je rozpozna po tym, czym są: przydatne narzędzie, a nie magiczna kula.

Z drugiej strony anty-wzorce są często obserwowanymi zachowaniami, które mają tendencję do obniżania jakości kodu. Ponownie, warto znać i rozumieć niektóre z nich, aby uniknąć takiego zachowania i spróbować je poprawić (uzasadnionymi argumentami), gdy zaobserwujesz go w innych. Niektórzy opisaliby nadużycie wzorów jako anty-wzór.

Wzory są zarówno destylowaną wiedzą programistów w książce kucharskiej, jak i użytecznym sposobem komunikowania się programistów.

Jak sugerują inne odpowiedzi, wzorce naprawdę są powszechnymi rozwiązaniami typowych problemów. Korzyścią jest to, że często można uzyskać lepsze rozwiązania, korzystając z istniejącego wzorca lub odkryć prawdopodobne pułapki przed rozpoczęciem kodowania.

Inną korzyścią jest rozmowa z kimś o kodzie. Wzory to inny rodzaj żargonu, który skraca długie opisy w kilku słowach. Spróbuj wyjaśnić „wtedy fabrycznie dodaje obserwatora” bez odwoływania się do wzorów. Możesz to zrobić, ale zajmuje to dużo czasu.

Większość programistów zwróci uwagę na każdy nowy paradygmat lub metodologię, która się pojawi. Zrobiłem to, kiedy po raz pierwszy usłyszałem o wzorcach projektowych. Wzory projektowe są właśnie tym, co sugeruje nazwa: projekt lub szablon do tworzenia klas i modelowania ich zachowania i interakcji w przewidywalny sposób

Spójrz na domy. Mają pewne podobieństwa. Każdy dom ma salon, kuchnię, sypialnię, łazienkę, toaletę na minimum. Nikt nie zbuduje domu bez łazienki, prawda? Apartamenty mają inny wzór niż bunglows. Zamki mają zupełnie inny wzór. Ubrania też mają wzory. Kurtka i formalna koszula mają ten sam podstawowy projekt, ale mają różne zachowania: nie będziesz nosić kowbojskiej kurtki na rozmowę kwalifikacyjną. Podobnie klasy i ich działania można pogrupować według ich zachowania i projektu. Patrzenie na wspólne elementy ich zachowań daje wzorce projektowe dla klas.

Rozumiem, że wzorce projektowe są ważne tylko wtedy, gdy głównym problemem są możliwość ponownego użycia i rozbudowy. Jeśli tworzysz małe aplikacje (powiedzmy mniej niż 10 klas), możesz ich wcale nie potrzebować. Ale duże projekty, szczególnie te, w których pracują duże zespoły i mają długie cykle konserwacji i dodawania funkcji, na pewno będą wymagały wzorców. Nie jest to nawet opcja w dużych projektach.

Rzuć okiem na samouczki online na temat wzorów. Wikipedia ma dobry zestaw artykułów. Ta strona też jest dobra: http://sourcemaking.com/ . Jeśli jesteś doświadczonym programistą, przekonasz się, że natknąłeś się na kilka wzorców, być może nawet sam zaimplementowałeś coś podobnego, nie znając tego po konkretnej nazwie.

Nie ignoruj ​​ich całkowicie! Możesz je uznać za przydatne w przyszłości, jeśli nie teraz. Kluczem do podejścia do wzorców projektowych z otwartym umysłem jest pytanie: „Co się stanie, jeśli nie użyję wzorów projektowych?” Wzory nie są rozumiane jako „lekarstwa” (chociaż można ich użyć jako lekarstwa na problem); raczej ucieleśniają powiedzenie „lepiej zapobiegać niż leczyć”.

Niemniej jednak przestrzegałbym przed obsesją na punkcie wdrażania wzorców, gdziekolwiek i kiedykolwiek zobaczysz niewielki pretekst do ich użycia. Problem ten napotkałem w jednym projekcie, w którym architekt był przekonany, że bez DP projekt byłby całkowitą katastrofą. Zebraliśmy się na spotkaniu grupowym, podczas którego inżynierowie zmienili projekt i wskazali, że wiele wzorów, które on polecił, w ogóle nie miałoby sensu, poza pokazaniem „wow, patrzcie na piękne wzory”. Potrzeba było wielu przekonujących i pewnych negocjacji, aby zmniejszyć liczbę miejsc, w których wzory były wykorzystywane tylko do potrzeb.

Ludzie, którzy odpowiedzieli, mają rację, jeśli chodzi o „programowanie oparte na wzorcach”, jak zwykle się uważa. Mam nieco inną definicję, która wydaje mi się bardziej odpowiednia do tego, co robię i zwykle używam „programowania opartego na wzorach” do opisania podejścia opartego na wtyczkach, a nie planowania.

Ponieważ programuję wtyczki jQuery, wtyczkę chmurową CMS i wtyczki eCommerce, „programowanie oparte na wzorcach” z tej perspektywy oznacza przyjrzenie się podstawowej technologii i istniejącym przypadkom użycia i trafienie w te najbardziej istotne statystycznie. W szczególności wtyczki muszą być bardzo oparte na wzorcach, aby dobrze pasowały do ​​kontekstu programowania.

Najlepiej jest jednak zastosować wzorzec PO Widzeniu prawidłowych przypadków użycia w wielu projektach, aby był statystycznie poprawny do ponownego użycia.