Jak ustalić, czy wzorzec projektowy jest poprawnie wdrożony?

Z powodzeniem mogę skalować wszystkie moje stare aplikacje, które nie korzystały z udokumentowanych wzorców projektowych. Jakikolwiek to jest wzór, nie wiem. W dużej mierze czułem potrzebę użycia prostych koncepcji OOP.

Koncepcja wzorców projektowych jest złożona i trudna do zrozumienia. Po wdrożeniu, jak ustalić, czy implementacja jest poprawna, a aplikacja posiada prawdziwe luźne połączenie?

Aby zachować zwięzłość odpowiedzi, powiedziałbym, że jeśli w kodzie widoczne są następujące cechy, możesz być pewien, że wzorce są na miejscu, nawet jeśli nie podjęłeś świadomych wysiłków (co nie jest problemem) w tym kierunku.

Pożądane cechy:

1. Twoja baza kodu jest testowalna na poziomie jednostki
2. Za każdym razem, gdy wdrażasz jakieś zmiany, wprowadzasz zmiany tylko w odpowiednich klasach, które są powiązane w domenie.
3. Baza kodu nie wykazuje entropii oprogramowania .

Jeśli nadal chcesz zidentyfikować i oznaczyć kod prawdziwymi nazwami wzorów, zaleciłbym wykonanie następujących czynności, aby uruchomić piłkę.

1. Inżynieria wsteczna bazy kodu, aby wygenerować kilka daigramów UML.
2. Porównaj wizualnie schematy z dowolnym gotowym odniesieniem do materiału odniesienia wzorów.

To powinno dać ci dobry pomysł.

Wspominasz zarówno wzorce projektowe, jak i połączenie. To są osobne koncepcje, więc zajmę się nimi osobno. Jedynym prawdziwym połączeniem jest to, że wzorce projektowe mają tendencję do promowania luźnego sprzężenia (ponieważ jest to główny aspekt dobrego projektu).

Wzorce projektowe

Koncepcja Wzorów projektowych jest w rzeczywistości dość prosta: to tylko zestaw szablonów, jak radzić sobie z najczęstszymi problemami. Są 2 główne powody, dla których są popularne:

1. Są „sprawdzone”: były używane wiele razy, a korzyści / wady każdego z nich są ogólnie znane, w szczególności znane są wszelkie subtelne problemy, które mogą powodować duże problemy.
2. Zapewniają wspólny zestaw terminologii, a tym samym umożliwiają łatwiejszą komunikację. Jeśli ktoś powie: „klasa X odgrywa rolę obserwatora we wzorcu obserwatora”, programiści znający ten wzorzec mogą natychmiast zrozumieć, co się dzieje.

Skąd wiesz, że poprawnie go wdrożyłeś? To trudne. W przypadku większości wzorów jest to proste - albo go zaśmiewałeś, albo nie. Niektóre wzorce są mniej wyraźne niż inne - np . Kontroler widoku modelu . Takie wzory lepiej wykorzystać jako ogólne wytyczne. Specyfika sposobu jego wdrożenia jest mniej ważna niż zrozumienie przyczyn istnienia wzorca i tego, co ma zostać osiągnięte.

Wzory projektowe nie są „jedyną prawdziwą drogą”. Często musisz albo dostosować je do swoich konkretnych celów, albo czasem nie będzie żadnych wzorów, które pasowałyby do wymagań. Wymuszanie wzoru, który nie pasuje, jest złym pomysłem; to jak używanie naprawdę dobrego młotka, gdy tak naprawdę potrzebujesz śrubokręta.

Sprzęganie

To naprawdę ważny pomysł w informatyce. Ponieważ wymagania dotyczące większości projektów oprogramowania zmieniają się z czasem (czasem znacznie), ważna jest zdolność projektu do radzenia sobie ze zmianami. Sprzężenie jest w zasadzie miarą „jak trudno byłoby wymienić ten komponent na inny?” „Składnikiem” może być metoda, klasa, pakiet, biblioteka itp.

W tym artykule w Wikipedii wymieniono różne typy sprzęgieł .

Odpowiedź jest właściwie celem, w którym chcesz pisać wzorce projektowe od samego początku. Dlaczego chcesz elastyczności?

To jest zmiana; wymagania się zmieniają. Spróbuj zmienić coś w swoich wymaganiach, które odzwierciedla zmianę kodu i przekonaj się, jak łatwo to zrobić.

Korzystanie z wzorców projektowych jest działaniem zapobiegawczym. Paterny projektowe służą do ułatwienia pracy podczas późniejszego skalowania aplikacji. Oczywiście, aby ułatwić sobie później pracę, musisz teraz wykonać trochę więcej pracy. więc prawdziwe pytanie brzmi: ile zmian możesz się spodziewać w przyszłości i co to za zmiana. Jeśli nie potrzebujesz skalowalności i elastyczności, możesz zrezygnować z wzorców projektowych.

Wzory projektowe same w sobie są implementacją Zasad Projektowania Zorientowanego Obiektowo. Dopóki będziesz przestrzegać tych zasad, twoje aplikacje będą elastyczne i skalowalne; nawet jeśli tak naprawdę nie masz rzeczywistego wzoru. Jak komentował powyżej Joachim Sauer, są to wspólne rozwiązania typowych problemów.