Wzory są złożone
Wszystkie wzorce projektowe należy stosować ostrożnie. Moim zdaniem powinieneś dokonać refaktoryzacji w kierunku wzorców, gdy istnieje ważny powód, aby to zrobić, zamiast natychmiast wdrażać wzorzec. Ogólny problem z używaniem wzorców polega na tym, że dodają one złożoności. Nadużywanie wzorców utrudnia dalsze rozwijanie i utrzymywanie danej aplikacji lub systemu.
W większości przypadków istnieje proste rozwiązanie i nie ma potrzeby stosowania żadnego konkretnego wzoru. Dobrą praktyczną zasadą jest użycie wzorca, gdy fragmenty kodu są zwykle zastępowane lub wymagają częstych zmian, i należy być przygotowanym na przyjęcie zastrzeżenia złożonego kodu podczas korzystania z wzorca.
Pamiętaj, że Twoim celem powinna być prostota i stosować wzorzec, jeśli widzisz praktyczną potrzebę wprowadzenia zmian w kodzie.
Zasady ponad wzorami
Używanie wzorców może wydawać się sporne, jeśli mogą one ewidentnie prowadzić do zbyt zaawansowanych i skomplikowanych rozwiązań. Jednak zamiast tego znacznie bardziej interesujące dla programisty jest zapoznanie się z technikami i zasadami projektowania, które stanowią podstawę większości wzorców. W rzeczywistości jedna z moich ulubionych książek o „wzorcach projektowych” podkreśla to , powtarzając, jakie zasady mają zastosowanie do danego wzoru. Są na tyle proste, że pod względem trafności mogą być przydatne niż wzorce. Niektóre zasady są na tyle ogólne, że obejmują coś więcej niż programowanie obiektowe (OOP), takie jak Zasada Zastępowania Liskova , o ile można budować moduły swojego kodu.
Istnieje wiele zasad projektowania, ale te opisane w pierwszym rozdziale książki GoF są całkiem przydatne na początku.
- Programuj jako „interfejs”, a nie „implementację”. (Gang of Four 1995: 18)
- Preferuj „kompozycję obiektów” zamiast „dziedziczenia klas”. (Gang of Four 1995: 20)
Pozwól tym na chwilę zagłębić się w ciebie Należy zauważyć, że gdy napisano GoF, interfejs oznacza wszystko, co jest abstrakcją (co oznacza również superklasy ), czego nie należy mylić z interfejsem jako typem w Javie lub C #. Druga zasada pochodzi z obserwowanego nadużywania dziedziczenia, które niestety jest nadal powszechne .
Stamtąd możesz przeczytać o zasadach SOLID, które zostały ujawnione przez Roberta Cecila Martina (aka. Wujek Bob) . Scott Hanselman przeprowadził wywiad z wujkiem Bobem w podcastu na temat tych zasad :
- S Ingle odpowiedzialności Zasada
- O pen Zamknięta Zasada
- Zasada podstawienia L iskova
- I nterface segregacja Principle
- D ependency Zasada Inwersja
Te zasady są dobrym początkiem do czytania i dyskusji z rówieśnikami. Może się okazać, że zasady przeplatają się ze sobą iz innymi procesami, takimi jak oddzielenie obaw i wstrzyknięcie zależności . Po pewnym czasie wykonywania TDD może się również okazać, że zasady te przychodzą naturalnie w praktyce, ponieważ trzeba do pewnego stopnia ich przestrzegać, aby stworzyć izolowane i powtarzalne testy jednostkowe.