Antywzorce

Kto koduje trochę dłużej z użyciem technik programowania obiektowego, ten zapewne zna ideę wzorców projektowych. Są one czymś w rodzaju przepisów na określone klasy i związki między nimi, które rozwiązują konkretne problemy. Przykładowo znany wzorzec Iterator stwarza uniwersalny sposób na dostęp do elementów kolekcji – niezależnie od tego, czy jest to lista, drzewo, zwykła tablica, itp.

Ale oprócz tych pożytecznych wzorców istnieją też… antywzorce. Zdecydowanie nie są one instrukcją, jak pewne fragmenty programów pisać. O nie, wręcz przeciwnie – mówią one, jak ich nie pisać i pokazują typowe oraz mniej typowe błędy popełnione we wszystkich fazach tworzenia oprogramowania.
Więcej o nich można poczytać choćby w Wikipedii. Zamieszczona tam lista jest niezwykle obszerna, ale trudno się dziwić – mówimy przecież o sposobach, jak zrobić coś źle, a w tej dziedzinie ludzkość ma wybitne osiągnięcia :)

Do ciekawszych (i pouczających) przykładów takich antywzorców należą chociażby:

• Magiczne liczby – obecność w kodzie wartości liczbowych (poza trywialnymi w rodzaju 0 czy 1) bez ich podpisania komentarzami lub pośrednictwa stałych
• Boski obiekt – klasa tak wielka i złożona, że zawiera się w niej cała funkcjonalność programu. Ktoś, kto używa takiego potworka najpewniej nie rozumie zasad programowania obiektowego i ma złe strukturalne przyzwyczajenia
• Magiczny przycisk – pisanie kodu wykonującego wewnętrzne czynności programu bezpośrednio w treści procedur zdarzeniowych interfejsu użytkownika
• Uniwersalny wytrych – stosowanie podobnego lub tego samego rozwiązania dla zupełnie odrębnych problemów
• Sekwencja pętla-switch – niezwykle “pomysłowy” sposób na zakodowanie kilku następujących po sobie czynności przy pomocy pętli i instrukcji wyboru, która zależnie od tego czy jest to 1., 2., czy N-ta iteracja wykonuje jakieś z góry ustalone czynności. Przyznam, że gdy to pierwszy raz zobaczyłem, nie mogłem wprost uwierzyć, że ktoś może wpaść na coś tak niedorzecznego

Jak widać ten antywzorce dotyczą wielu różnych aspektów programowania i projektowania, i czasami ich niepoprawność wcale nie jest taka oczywista. (Chociaż na pewno ostatnia pozycja z listy powyżej jest aż nazbyt oczywista). Warto zatem zapoznać się z nimi; dzięki temu możemy znaleźć inspirację zarówno do unikania błędów, jak i ich popełniania ;]

Be Sociable, Share!

• 
• 

Be Sociable, Share!

• 
• 

• Tweet
•