BAD DESIGN czyli zły projekt

Czym jest tzw. "zły projekt" (BAD DESIGN)
Niestety obecnie w dobie masy frameworków, bibliotek i innych gotowych komponentów korzystając z tych udogodnień zapomina się w ramach projektowania aplikacji czy nawet wielkich systemów o tak podstawowych zagadnieniach jak dobre zaprojektowanie systemu czy aplikacji. Napisałem "niestety", ponieważ złe zaprojektowanie prowadzi nieuchronnie do klęski w postaci:

• błędów kodu trudno wykrywalnych lub niemożliwych do wykrycia (często rozwiązywanych np. poprzez cykliczne restarty systemów)
• frustracji ludzi / programistów którzy są zmuszeni do utrzymywania systemu 
• braku możliwości jakiegokolwiek rozwoju aplikacji czy systemu lub możliwości znacząco utrudnionych
• ogromnych kosztów wymaganych na rozwój czy poprawę systemu / aplikacji

Wykorzystanie udogodnień jakie w dzisiejszych czasach występują znacząco ułatwia projektowanie systemów jednakże sprawia również, że używając ich następuje tzw. rozleniwienie i oczekiwanie, że zastosowane bibliotek / frameworków zwalnia od myślenia o dobrym projekcie. No dobrze, ale co to jest "złe zaprojektowanie" lub czym się charakteryzuje ? Zadając to pytanie, najprawdopodobniej padnie tyle odpowiedzi ilu ludzi będzie zaangażowanych w debatę i pewnie każdy będzie miał po części rację. Natomiast pytanie brzmi, czy są bezsporne kryteria złej architektury, z którymi są w stanie zgodzić się architekci / inżynierowie, a jeżeli tak to jakie to są kryteria. Niżej przedstawiam propozycję cech, zaczerpniętych z publikacji internetowych, którymi charakteryzuje się zła architektura (myślę, że do zaakceptowania dla każdego inżyniera):

• system, który jest ciężki do zmiany z uwagi na fakt, że każda wprowadzona zmiana ma wpływ na znaczącą ilość elementów systemu (Rigidity)
• system, w którym wprowadzenie zmiany w jakimś kawałku kodu powoduje błędy lub uszkodzenia w nieprzewidywalnych innych miejscach systemu (Fragility) 
• system, w którym komponenty zostały tak zaprojektowane, że są niemożliwe do wyodrębnienia z tego systemu w celu użycia ich w innym systemie (Immobility) 

Oczywiście nie są to jedyne cechy błędnego projektu czy architektury, jednak gdy te w/w występują w projekcie systemu bezspornie można uznać ten projekt za błędy czyli przykład BAD DESIGN.

Wzorce projektowe

Wzorce projektowe to udokumentowane reużywalne rozwiązania dla problemów projektowych. Cechy wzorców projektowych:

• posiadają nazwy: Composite, Singleton ....
• nie są same w sobie komponentami
• pociągają za sobą wymienność
• mogą być implementowane w różny sposób oraz w różnych kontekstach
  

Istotną kwestią jest by używać wzorców projektowych tylko tam, gdzie jest to naprawdę potrzebne. Dlaczego ? Ponieważ:

• większość wzorców sprawia, że projekt staje się bardziej złożony
• każdy wzorzec posiada swoje zamienniki
• wzorce projektowe nie są "najlepsze" tylko dlatego, że są poprostu jedynie wzorcami

Adapter	Konwersja interfejsu określonej klasy na inny interfejs oczekiwany przez klienta.
Proxy	Dostarczenie środka zastępczego dla obiektu w celu kontroli dostępu do niego.
Composite	Kompozycja obiektów w hierarchii typu część-całość tak, że klient może traktować zarówno pojedyncze obiekty jak kompozycję jednakowo.
Template Method	Definicja szkieletu algorytmu określonej operacji oraz umożliwienie przedefiniowania części kroków tego algorytmu w klasach pochodnych.
Singleton	Zapewnienie, że określona klasa posiada wyłącznie jedną instancję oraz dostarcza punkt dostępu do niej.