Wątek przeniesiony 2019-08-14 11:27 z przez Shalom.

Stosowanie wzorców projektowych w pracy.

Odpowiedz Nowy wątek
2019-08-14 11:05
0

Witam wszystkich.
Jak to jest ze stosowaniem wzorców projektowych ? W okresie próbnym w pracy przestawiłem się na stosowanie wzorców projektowych, praktycznie wszędzie. Dla przykładu chcę sklonować dwa obiekty, odrazy chwytam za wzorzec Prototyp i szukam przykładowej, najprostszej implementacji w internecie. Faktycznie wtedy praca mi idzie wolniej. Co ciekawe zwróciłem uwagę, że inni programiści nie stosują wzorców projektowych praktycznie w ogóle, może tylko czasami. Czy coś ze mną nie jest tak ? Czy stosować wzorce projektowe gdzie się da, czy nie. Dzięki za informacje i wskazówki :)

Pozostało 580 znaków

2019-08-16 07:34

mi się wiele razy zdarzyło użyć prawie wzorca projektowego którego nawet nie znałem - zorientowałem się że używam czasem wzorco-podobnych rozwiązań dopiero jak zacząłem czytać o jakiś tam wzorcach ;D

Pozostało 580 znaków

2019-08-16 12:36
10

Jeśli w czasie pracy zastanawiasz się "jakiego wzorca projektowego użyć do rozwiązania problemu X" to znaczy, że tu jest problem. Powinieneś raczej podejść tak:

  • widzę, że trzeba zrobić X
  • potrzebuję by to zachowywało się tak i tak
  • ok, znam podejście, które się tutaj sprawdzi

I to podejście to jest właśnie wzorzec. Część wzorców się będzie używało nawet nie znając ich nazw bo "po prostu już to kiedyś robiłem".

Pozostało 580 znaków

2019-08-18 18:22
6

@hauleth podał bardzo fajny opis stosowania wzorców w praktyce. Na pewnym etapie, który wynika z doświadczenia, wzorce po prostu zaczynają „same się stosować”. Ich urok polega na tym, że są powszechnie znanymi i akceptowanymi rozwiązaniami typowych problemów. Jeżeli potrafisz zidentyfikować problem jako „typowy”, to stosujesz „powszechnie znane i akceptowane” rozwiązanie.

Warto tu jednak pamiętać, że niektóre narzędzia narzucają stosowanie wzorców. Szczególnie frameworki mają tendencję do standaryzacji rozwiązań. To może powodować, iż niestandardowy problem będzie bardzo trudny do rozwiązania, bo narzędzie będzie utrudniać nam pracę.

Pozostało 580 znaków

2019-08-23 11:19
3

Pierwsza rzecz jaka chciałbym od siebie dodać to przestroga, że informacje jakie możesz znaleźć w książkach czy internecie niemal zawsze nie przedstawiają kontekstu, a bez kontekstu ciężej jest zweryfikować czy dana rzecz ma sens w Twoim konkretnym projekcie. Dlatego jeśli chcesz zachować umiar to zrozum pierw potrzeby i ograniczenia projektu (zwróć też uwagę na zespół i samą firmę).

Potrzeby to przepustka na wprowadzenie słusznych zmian. Jeśli chcesz coś poprawić, zapytaj zespół co go najbardziej wkurza w projekcie, a potem namierz cel i zlikwiduj. Nie skupiaj się na problemach, które tylko Ciebie drażnią. Patrz na projekt z perspektywy zespołowej.

Druga rzecz to ograniczenia. One też są dobre. Dzięki nim wiadomo kiedy się zatrzymać. Ograniczenia pomagają przy projektowaniu, one pomagają skreślić z listy te rozwiązania, które nie pasują do projektu.

Z perspektywy projektu chodzi też o złapanie balansu. Zauważ, że gdy wprowadzasz jakaś technikę to wpływasz na ten balans, ponieważ każda technika jednocześnie coś daje i zabiera. Dlatego przed wprowadzeniem zmian nie patrz tylko na to co dostaniesz, pomyśl dwa razy dłużej nad tym co w ten sposób stracisz. Inaczej Twój projekt stanie się zbyt wcześnie trudny w utrzymaniu.

Poza tym wszystkim warto znać kilka styli pisania kodu, wtedy będziesz miał większe szanse, że wybierzesz technike, która lepiej wpasuje się w potrzeby projektu. Inaczej będziesz miał młotek, a wszystko inne będziesz traktował jak gwoźdź - to jest trochę słabe. Najlepiej wybieraj języki inne (jeśli masz język statycznie typowany to wybierz dynamiczny), poznaj też funkcyjne programowanie. Ostatecznie warto pisać w takim języku, który nie prowadzi Cię za rączkę i pozwala pisać kod różnymi stylami.

edytowany 2x, ostatnio: nohtyp, 2019-08-23 11:21

Pozostało 580 znaków

2019-08-23 11:43
1

Warto jednak znać podstawowe wzorce, by nie pisać obiektu o nazwie Builder, który jest singletonem i działa jak fabryka.

Pozostało 580 znaków

2019-08-25 23:59
1

Wzorce są ok, bo wprowadzają wspólne słownictwo: jak mówię „dekorator” albo „listener”, to od razu wszyscy rozumieją, co mam na myśli.

Z drugiej strony, zawsze się trochę krzywię, bo kojarzą mi się z przemądrzałymi, pretensjonalnymi architektami. Ach te rozmowy kwalifikacyjne o tym, czym jest i czym nie jest „adapter”, albo wymienianie jak największej liczby wzorców projektowych w znanych bibliotekach. Im więcej mądrych słów używasz, tym wydajesz się mądrzejszy. Tylko że nie.

Pokaż pozostałe 3 komentarze
@Charles_Ray: w ten sposób przynajmniej dowiesz się czy ma podstawy, resztę może zawsze się douczyc. Gorzej jak nie ma pojęcia o czym mówi a to łatwo wywnioskować zadajac kilka pytań - xxx_xx_x 2019-08-29 19:44
Ja na szybko nie umiałem wymienić, że java.util.Iterator to Iterator. Jestem beznadziejnym kandydatem. - Pijany Krawiec 2019-08-29 20:36
@Pijany Krawiec: głupoty opowiadasz albo trafiles na idiote rekrutera. Takie pytania mają wybadac co kandydat wie i jak myśli. Przecież o coś musisz zapytać w kwestii architektury, w koncu nie bierzesz kandydata na piękne oczy. - xxx_xx_x 2019-08-29 20:48
Coś mi tu nie gra w Twoich komentarzach, ale niech tak zostanie. Nie wiem co ma iterator do architektury. Nie wiem co daje umiejetność wyrecytowania wzorców jakie zna. Ale to moje zdanie, miłej nocy :) - Charles_Ray 2019-08-29 22:30
Nie chodzi o recytowanie, wystarczy że opiszę je mniej więcej, oraz odpowie na kilka pytań i wiesz czy wie o czym mówi czy tylko recytuje. Poza tym to otwiera temat do luźnej dyskusji. Gdzie używał tych wzorców w jakim celu itp. - xxx_xx_x 2019-08-29 23:04

Pozostało 580 znaków

2019-08-29 15:42
1

Dodam jeszcze że warto stosować wzorce jeżeli przewidujemy że dany komponent będzie się zmieniał w jakimś kierunku, wtedy można od razu zastosować właściwy wzorzec.
Przykład :
Chcemy notyfikować naszego partnera handlowego przez odpalenie linku

  1. jeżeli ukryjemy link pod jakąś metodą, to pojawi się problem z obsługą kilku partnerów.
  2. Możemy użyć buildera, wtedy będzie łatwiej parametryzować url.
  3. Może będzie trzeba wysyłać różne dane do różnych partnerów, wtedy lepiej dekorator.
  4. Może będziemy chcieli wywoływać tę operacje z wielu miejsc wtedy można dodać command lub strategy

Im więcej wiemy o tym jaki będzie kierunek zmian/rozwoju możemy podjąć lepsze decyzje czy używać wzorca czy nie ma takiej potrzeby.

Pozostało 580 znaków

2019-09-05 10:22
2

Z wzorcami projektowymi jest tak:

  1. Są przydatne i należy je znać i stosować.
  2. Dużo tutoriali w internecie zawiera elementarne błędy na temat sposobów ich implementacji.
  3. Nie spotkałem jeszcze źródła, które oprócz samego wzorca, opisuje też sensowne przypadki użycia, żeby czytający mógł skumać po co to istnieje i kiedy należy używać.

Spotkałem natomiast masę programistów na różnych stopniach rozwoju zawodowego (w szczególności midzi i bieda seniorzy), którzy uważają, że wzorce to bullshit, nie ma o tym co czytać, program ma działać, czy mój hit "ja jeszcze nigdy nie napisałem interface'u". Oczywiście jest dość liczna grupa, która używa wzorców, bo je obczaiła z przykładów użycia jakiś zewnętrznych bibliotek, ale nie zna ich nazw - dla mnie OK. Według mnie, bez "czucia" wzorców, nie da się wyjść powyżej widoku pojedynczej metody, ew. klasy w kodzie. Jeżeli nawet za pierwszym razem, ktoś spędzi więcej czasu na nauce jakiegoś wzorca, to za drugim razem wykona podobne zadanie szybciej, czytelniej i z mniejszym ryzykiem błędu, więc tak - warto używać wzorców, natomiast potrzeba do tego sporej praktyki, żeby wiedzieć których kiedy i w jakich wypadkach iść we własne pomysły.

edytowany 1x, ostatnio: piotrpo, 2019-09-05 13:45

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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