Powiedzmy jak się robi aplikacje na 3000 linijek kodu (PHP) to czy warto się zajmować wzorcami projektowymi czyli układem klas funkcji, No bo w zasadzie nie mogę znależć nigdzie w sieci programu do robienia wzorców projektowych, a nie będę go robił na kartce.
- Rejestracja:ponad 10 lat
- Ostatnio:ponad 3 lata
- Postów:1181
- Rejestracja:około 17 lat
- Ostatnio:2 minuty
2
pol90 napisał(a):
w zasadzie nie mogę znależć nigdzie w sieci programu do robienia wzorców projektowych, a nie będę go robił na kartce.
Co ty chcesz robić na kartce?
Może chcesz rysować schematy UML-a? Od tego jest dużo narzędzi, np: http://www.umldesigner.org/
Wzorce projektowe to standardowe metody projektowania/kodowania algorytmów.
masz przykładowo takie wzorce (te co mi od razu do głowy przychodzą):
- budowniczy
- fabryka
- wizytator
- adapter
- fasada
- obserwator
- strategia
- kompozyt
- .....
Wiele z tych wzorców ludzie stosują nieświadomie.
Celowo nie wymieniłem singletona, bo to powinno być traktowane jako antywzorzec (każdy newbie się na niego rzuca, bo najprostszy ze wszystkich wzorców, a jest najmniej użyteczny, a wręcz najbardziej szkodliwy).
edytowany 3x, ostatnio: MarekR22
- Rejestracja:około 7 lat
- Ostatnio:około 2 miesiące
- Postów:365
3
https://exceptionnotfound.net/tag/design-patterns/ - dobry blog, jeszcze lepiej opisane wzorce projektowe oraz https://exceptionnotfound.net/tag/anti-patterns/ . Warto przeczytać przy kawie.
- Rejestracja:około 11 lat
- Ostatnio:około 4 godziny
- Postów:8409
6
O właśnie mi o UML chodziło coś nie mogę rożróżnić tego od wzorców projektowych.
No to nie rozumiesz idei wzorców projektowych i lepiej się zatrzymaj i spróbuj zrozumieć, co to w ogóle jest.
Wzorce projektowe to sposób, w jaki można połączyć ze sobą poszczególne części kodu ze sobą. One są niewidoczne i przenikają kod. Wzorzec projektowy to jak zwyczaj, np. zwyczaj jedzenia pierogów w Wigilię. Tak samo zwyczajem może być specyficzny sposób tworzenia obiektów, żeby w odpowiedni sposób współpracowały ze sobą.
A UML to sposób zapisu graficznego, sposób rysowania diagramów. Czyli UML to będzie rysunek pieroga.
Powiedzmy jak się robi aplikacje na 3000 linijek kodu (PHP) to czy warto się zajmować wzorcami projektowymi czyli układem klas funkcji,
To nie ma nic do rzeczy. 3000 linijek kodu to nie jest to już raczej Hello World, więc już jest tu pewna złożoność, zapewne ileś modułów, czyli pełno okazji do zaimplementowania wzorca (a jeden "wzorzec projektowy" można zaimplementować nawet w kilku/nastu linijkach kodu, więc w 3000 linijkach to by się zmieściły pewnie z setki wzorców).
Tylko nie o to chodzi wcale. Wzorce projektowe mają do czegoś służyć, rozwiązywać jakieś konkretne problemy, a nie być wrzucane na siłę, bo można. Myśl o problemach, które musisz rozwiązać i czy dany wzorzec rozwiązuje problem, a nie o tym, czy warto się zajmować wzorcami projektowymi, bo to pytanie jest totalnie od czapy.
edytowany 3x, ostatnio: LukeJL
Oczywiście tylko żeby stwierdzic: o tutaj mógłbym użyć strategii a tutaj fasady to trzeba wzorce przynajmniej kojarzyć.
Niekoniecznie kojarzyć, tylko umieć stosować umiejętnie, i nie stosować, kiedy nie trzeba. Używanie fasady bez opamiętania kończy się robieniem wrapperów do wszystkiego i overengineeringiem. Ew. tworzeniem frameworków, które pozwalają w teorii napisać coś za pomocą kilku linijek kodu, a w rzeczywistości są wyciekającą abstrakcją i żeby napisać coś zaawansowanego w nich i tak trzeba będzie sięgnąć pod maskę. Każdy wzorzec niewłaściwie wykorzystany staje się szkodliwy.
Wzorce projektowe to trochę jak nóż, niektórzy nim kroją chleb, a niektórzy w ogóle lepiej, żeby go nie dotykali.
Zgadzam się z tym co napisałeś w wiadomości: "Wzorce projektowe mają do czegoś służyć, rozwiązywać jakieś konkretne problemy, a nie być wrzucane na siłę, bo można". Popieram w 100%.
Mój komentarz odnosił się do części: "Myśl o problemach, które musisz rozwiązać i czy dany wzorzec rozwiązuje problem". Mógłbyś napisać jak chciałbyś odpowiedzieć na to pytanie bez podstawowej / pobieżnej znajomości wzorców. Moją myśl napisał bardziej rzeczowo cerrato w poście niżej. Gdy ja pisałem odpowiedź do Ciebie to jeszcze nie przeczytałem jego wiadomości.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
2
Zamiast pytać się czy warto (...) po prostu sprawdź.
Jak Cię to ciekawi oczywiście. Bo jeśli tylko dla szpanu na osiedlu - to nie warto.
https://phptherightway.com/pages/Design-Patterns.html
https://www.tutorialspoint.com/php/php_design_patterns.htm
https://www.ibm.com/developerworks/library/os-php-designptrns/index.html
https://code.tutsplus.com/series/design-patterns-in-php--cms-747
https://www.udemy.com/design-patterns-through-php/
https://helion.pl/ksiazki/php-obiekty-wzorce-narzedzia-wydanie-v-matt-zandstra,phpob5.htm#format/d
https://www.packtpub.com/application-development/mastering-php-design-patterns
https://www.apress.com/it/book/9781484224502
edytowany 1x, ostatnio: vpiotr
4
Moim zdaniem musisz mieć w głowie dwie rzeczy odnośnie wzorców (chociaż w sumie to ta uwaga dotyczy też wielu innych rzeczy z programowaniem związanych)
1) Powinieneś wzorce w miarę kojarzyć. Nie mówię, żebyś miał na pamięć wykute wszystkie szczegóły dotyczące każdego wzorca, bo to sobie znajdziesz w razie potrzeby. Ale musisz je na tyle kojarzyć, żeby umieć załapać, w jakiej sytuacji dany wzorzec może być przydatny. Nie znając ich wcale, nawet nie będziesz wiedział, czego masz szukać
2) Jak napisałem powyżej - wzorce bywają przydatne w różnych sytuacjach, więc niekoniecznie w każdym projekcie da się z nich skorzystać. To trochę jak z programowaniem obiektowym albo z rekurencją - są fajne, ale nie wszędzie pasują. I tak, jak na siłę nie ma co pchać wszędzie OOP, tak jak są tematy, które się lepiej i bardziej naturalnie rozwiąże bez rekurencji, tak samo nie zawsze do danego projektu da się wprowadzić w sensowny sposób dany wzorzec/wzorce. Oczywiście - na upartego można, ale nie będzie to miało sensu, nie zwiększy także czytelności czy możliwości rozbudowy kodu.
Jakby nie patrzeć, pkt. 2 wynika z pierwszego. Żeby móc ocenić, czy w danej sytuacji da się wykorzystać jakiś wzorzec (a także wybrać odpowiedni), najpierw powinieneś się z nimi zapoznać i w miarę je kojarzyć.
Zobacz pozostałe 11 komentarzy
@m123 Przede wszystkim duże obycie z kodem. Ludzie dzisiaj za wcześnie się uczą wzorców, zamiast dać sobie czas na pisanie projektów i chłonięcie powoli wiedzy. Ktoś kto dużo się napisał kodu, ale nie zna w ogóle wzorców i wejdzie do projektu, gdzie będą używane wzorce X, Y i Z - po prostu poczyta coś już w pracy o wzorcach i potem będzie już rozumiał (może nawet się okazać, że sam je nieświadomie stosował). A ktoś kto się wyuczył wzorców na pamięć, ale nie ma dużego "przebiegu", nie napisał wielu projektów w swoim życiu, zwykle tych wzorców po prostu i tak nie zrozumie
Czyli: praktyka > teoria.
pamiętaj, jeszcze, że w niektórych językach są specyficzne wzorce (np w C++ jest RAII - resource acquisition is initialization), nie znam PHP, ale też może coś takiego mieć.
W PHP to pewnie spaghetti code jest najpopularniejszym wzorcem xD
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 4 lata
- Lokalizacja:Piwnica
- Postów:7697
1
Do PHP masz PSR, ponadto robiąc w miarę uważnie w frameworkach zwykle poznajesz też i wzorce, chyba, że robisz na odpierdziel to nie.
- Rejestracja:ponad 9 lat
- Ostatnio:10 miesięcy
- Postów:1788
3
@pol90: ja już Ci kiedyś pisałem, czym się powinieneś zainteresować.
Przeczytaj tą książkę:
https://helion.pl/ksiazki/refaktoryzacja-ulepszanie-struktury-istniejacego-kodu-martin-fowler-kent-beck-john-brant-william-opdy,refukv.htm
I posprzątaj jeden ze swoich projektów. Wzorce projektowe Ci nie pomogą na razie. Wzorce wymienione przez @MarekR22, to wzorce używane przy skomplikowanych regułach biznesowych, a Ty takich nie masz. Może z wyjątkiem fabryki i strategii. Te dwa wzorce możesz ogarnąć, bo się często przydają.
Musisz nauczyć się lepiej nazywać zmienne, tworzyć mniejsze klocki, tworzyć mniej skomplikowany kod. Poczytaj na temat SOLID. A zwłaszcza na temat SRP (S z solid) i OCP (O z solid). Dodając do swojego kodu wzorce projektowe na siłę spowodujesz, że będzie jeszcze mniej czytelny. Skup się na single responsibility principle i podstawowych rzeczach, takich jak nazewnictwo zmiennych.
edytowany 2x, ostatnio: Desu
No tym się właśnie już zajmuje, a pytałem tylko o te wzorce ze względu na dostanie pracy.
Bardziej Ci pomoże to, co wyżej napisałem, niż nauczenie się jakiegoś abstract factory, bo pewnie większości tych wzorców nie zrozumiesz dopóki nie będziesz musiał ich zastosować w pracy, a jak będziesz miał ładny i schludny kodzik zgodny z SRP i dobrym nazewnictwem, to zrobisz lepsze wrażenie, niż cytując z książki co robi kompozyt.
No ja właśnie teraz mówię, że tym się teraz zajmuje co mi zasugerowałeś wyżej.
No i super, trzymam kciuki :)
Możesz wrzucić do oceny kod po takim zabiegu. Najlepiej wrzuć go na githuba, a czyszczenie przeprowadź na osobnym branchu, to bedzie łatwiej zobaczyć, co poprawiłes.
- Rejestracja:ponad 6 lat
- Ostatnio:8 dni
- Postów:3561
1
wzorce nie są jakąś religią która obowiązuje do wykonania (choś ta religia na wyznawców, i to bardzo szkodliwe)
Podoba mi sie określenie @LukeL "jak pierogi w wigilię"
Inne: jak stolarz do stolarza mówi: to trzeba złączyć na pióro. Sprawna i krótka komunikacja między fachowcami z branży
slawekh666