blog programisty - wzorce projektowe

Najlepsze Praktyki Programistów

Popularne rozwiązania częstych problemów jakie narastają podczas projektowania oprogramowania.

Wzorce czyli rozwiązania popularnych problemów jakie narastają podczas projektowania oprogramowania. W kolejnych iteracjach tego wpisu będą się pojawiać następne wzorce projektowe. W efekcie końcowym będzie tutaj większość popularnych wzorców. Będą one również dostępne na githubie w formie projektu napisanego w Javie i Kotlinie, wraz z dołączonymi do nich testami. Pracy jest dużo, także nie zwlekając. Zaczynamy!

Co tutaj znajdziesz?

Wzorce Projektowe:

  • TEN POST – krótkie omówienie każdego wzorca
  • OSOBNE POSTY – implementacja i szczegółowe omówienie poszczególnego wzorca

Projekt na Githubie:

  • porównanie implementacji w Javie Kotlinie.
  • testy w Groovym (Spock)
  • budowane na Gradle.

Link do GitHuba »

Omówienie konkretnych wzorców

Creational Design Patterns:
Structural Design Patterns (wkrótce)
Behavioral Design Patterns (wkrótce)

Jeśli lubisz książki to polecam przeczytać:  Rusz Głową – Wzorce Projektowe

O wzorcach słów kilka…

Bycie programistą to ciągłe rozwiązywanie problemów. Jak to w IT bywa, zawsze znajdzie się złoty środek na wszystko. Tak i tutaj na białym rumaku przyjeżdża wybawiciel — wzorce projektowe. Rozwiązanie wszystkich naszych problemów! Rzeczywistość nie jest tak kolorowa. Nigdy nie było i prawdopodobnie nie będzie czegoś takiego jak Silver-Bullet. Dobra to po co w ogóle zawracać sobie tym głowę? Przecież umiem napisać kod, który działa. Nie potrzeba mi nic więcej! Pewnie tak jest, ale nie każdy jest wróżbitą. Nie jest łatwym zadaniem czytanie czyjegoś kodu i zastanawianie się co on zrobił i po co? Tutaj wzorce odgrywają swoją rolę. Jest to zestaw standardów dzięki, którym można ułatwić pracę sobie i innym. W teorii ułatwia to czytanie i utrzymanie aplikacji.

Dobra to wiemy, że wzorce to takie zbiory popularnych problemów, które zostały już rozwiązane przez innych ludzi, można zająć się implementacją. ehh…Tutaj jest kolejna bolączka. Jest to tylko opis rozwiązania, a nie jego implementacja. Nie są to gotowe rozwiązania, ale tylko abstrakcyjne przemyślania co do rozwiązania popularnych problemów.

Wzorce rozwiązują tylko problemy generacji i interakcji między obiektami. Nie rozwiązują problemów architektonicznych. Są to uogólnione rozwiązania w formie szablonów, które mogą być zastosowane do realnych problemów podczas wytwarzania oprogramowania.

Dobra, dobra, ale jak to może mi się przydać?

Załóżmy, że chcesz pokazać aplikację swojemu kumplowi. Okazuje się, iż potrafi on programować. Pół drogi za tobą! Tłumaczysz mu wstępny zarys aplikacji i do czego może ona być wykorzystana. Po długiej drodze zawiłych pytań i odpowiedzi w końcu przychodzi czas na pokazanie kodu. Właśnie w tym miejscu wzorce mogą odegrać decydującą rolę. Jeśli napisałeś to z użyciem wzorców jest dużo większe prawdopodobieństwo, że będzie chciał współtworzyć z tobą aplikację. Pozwoli mu to w prostszy sposób dowiedzieć się co tam zaimplementowałeś. Kolejny przykład rozmawiasz z tym samym kumplem (bo masz mało znajomych) i omawiacie różne rozwiązania do danego problemu. Próbujesz opisać swoje rozwiązanie. Mówiąc, że zastosowałeś ‚tutaj’ wzorzec X ułatwi wam to komunikację (albo chociaż pozwoli wam udawać, że wiecie o czym rozmawiacie). Pisanie kodu jest proste schody zaczynają się gdy trzeba zaimplementować system, który jest łatwy w utrzymaniu i skalowaniu.

Co tam jeszcze w tych wzorcach?

  • mogą pomóc w rozwiązaniu częstych problemów jakie się pojawiają podczas tworzenia kodu
  • możesz dowiedzieć się ciekawych konstrukcji, na które sam nie wpadniesz zbyt szybko
  • oszczędza twój czas, oszczędza czas innych, przyspieszy czas tworzenia aplikacji
  • łatwiejszy w utrzymaniu kod, wygląda ‘ładniej’ jeśli widzisz dobrze zaimplementowane konstrukcje
  • sama koncepcja wzorca jest prosta w zrozumieniu – implementacja niekoniecznie zawsze będzie elegancka
  • no bo w programowaniu chodzi też o rozwój i warto poszerzać swój warsztat

Podział wzorców:

  • Creational Design Patterns  zapewnia tworzenie obiektów w możliwie najlepszy i elastyczny sposób
  • Structural Design Patterns – zapewnia lepszą strukturę obiektu. Choćby większy obiekt stworzony z małych.
  • Behavioral Design Patterns – zapewnia lepsze połączenie, komunikację między obiektami.

Słowem Podsumowania

Jak powiedział Martin Fowler wzorce to tylko pół-produkty, trzeba je dokończyć, aby wprowadzić je do swojego kodu. Nie ma czegoś takiego jak Silver-Bullet. Nigdy nie próbuj wprowadzać problemu do wzorca, zamiast tego wprowadź wzorzec do problemu. Drobna, a jednak znaczna różnica. Jeśli musisz dostosować swój problem do wzorca projektowego to prawdopodobnie nie jest to odpowiedni wzorzec do tego problemu. Oczywiście jak wszystko tak i to stosujmy to z głową – nie popadając w skrajności. Bądźmy profesjonalistami, unikając przesadnego perfekcjonizmu. Sam perfekcjonizm, może być zabójczy. Jako off-topic od wzorców polecam poniższy materiał : )

Lista wszystkich wzorców projektowych oraz zasad projektowych

 

§ Creational Design Patterns 

SINGLETON – obiekt tworzony tylko raz

SINGLETON – Porównanie 9 Implementacji »

Prawdopodobnie najpopularniejszy wzorzec, który jest prosty do zrozumienia. Umożliwia utworzenie tylko jednej instancji, która ma globalny dostęp. W praktyce sprowadza się do tego, że nie można utworzyć obiektu bezpośrednio poprzez new Singleton, a robimy to poprzez wywołanie globalnej instancji obiektu Singleton.getInstance(). W większości przypadków jest uważany za anty-wzorzec i często da się obejść bez niego. Łatwo jest zaimplementować go w złym miejscu.

Chwila refleksji:

Jak stworzyć obiekt, który będzie można utworzyć tylko raz? Wbrew pozorom nie jest to łatwe pytanie : ) 

 

FACTORY – obiekt tworzony gdzieś indziej

FACTORY – oddelegownie tworzenia obiektu »

Wzorzec Factory pozwala oddelegować tworzenie obiektu do innych klas. Jest to przydatne w momencie gdy mamy do stworzenia obiekt, który jest powiązany z wieloma innymi obiektami. Weź przykład gdzie masz 13 zależności. Czy będziesz szukać każdej z nich za każdym razem jak chcesz skorzystać z obiektu? Nie. Tutaj może przydać się koncepcja tego wzorca. Polowanie na każdą zależność może być problematyczna, dlatego dodając trochę więcej złożoności do kodu, ułatwiamy finalne tworzenie oczekiwanego obiektu.

 

Structural Design Patterns (wkrótce)

Behavioral Design Patterns (wkrótce)

„Tysiącmilowa podróż zaczyna się od pierwszego kroku” – Konfucjusz

 

Zdjęcie główne autorstwa: Dom Dada

53 Udostępnień