Wraz z modą na Agile i SCRUM pojawiło się kilka technik projektowania oprogramowania, które wynikały z praktyki architektów i programistów wykorzystujących techniki zwinne w swojej pracy. Jedną z tych technik jest SOLID należący do gamy „narzędzi” OOD (Object Oriented Design).

Jak zwykle małe wprowadzenie/przypomnienie – SOLID to akronim powstały z pierwszych liter wytycznych, jaki powinien trzymać się architekt czy deweloper przy tworzeniu projektu. I tak mamy:

  • S ingle Responsibility Principle – czyli zasada pojedynczej odpowiedzialności – opiszę to za chwilę dokładniej bo jest to temat  naszej notki…
  • O pen Close Principle - otwartość na rozszerzanie, zamknięcie na modyfikacje  – klasa, funkcja, metoda powinna być otwarta na rozszerzanie, ale zamknięta na modyfikację
  • L iskov Substitution Principle - klasa dziedziczona powinna być substytut bazowej w ramach metod bazowej, czyli jeżeli np. twoja metoda oczekuje klasy bazowej powinieneś móc podstawić dowolną klasę z niej dziedziczoną bez zmiany jakichkolwiek efektów. – btw, to chyba jedna ze starszych zasad włączonych do solida
  • I nterface Segregation Principle - zasada segregacji interfejsów, czyli unikanie budowania przeciążonych „grubych” interfejsów, a dopasowanie bardziej do potrzeb i podstawowej funkcji klienta
  • D ependency Inversion Principle - zasada odwracanie zależności – szczegóły zależą od abstrakcji, moduły niskopoziomowe zależą od wysokopoziomowych – to w sumie też temat na oddzielną notkę…

Tyle wstępu, tak jak obiecałem skupimy się na SRP oraz na pewnym niepożądanym ekstremistycznym podejściu do tej, chyba najważniejszej, zasady.

Generalnie SRP ma za zadanie dbać o to, aby projektowane klasy i metody miały jedną główną funkcję. Definicja SRP brzmi „Żadna klasa nie może być modyfikowana z więcej niż jednego powodu„. Stoi to w opozycji do freestyle’owego projektowania, które owocuje kilkoma klasami w programach realizujących po kilkaset funkcji. Doskonałą parafrazą tego, co można spotkać w nie SOLIDowych projektach jest poniższy obrazek:

Jednak SRP ma też kilka wad, a chyba najpopularniejszą jest ekstremizm, w jaki popadają projektanci. Przypuszczam, że jeżeli pracowałeś zgodnie z zasadami SOLID bez problemu przypomnisz sobie sytuacje, gdy wstępny projekt tworzony przez kogoś, kto pierwszy raz dotknął tej techniki przypomina bardziej definicję języka, w jakim ma powstać projekt niż coś funkcjonalnego. W skrajnym przypadku klas może być prawie tyle ile instrukcji w języku multiplikowanych przez ich kombinacje. Może to trochę przerysowane, ale niestety  prawdopodobne…

Częściej można spotkać inną sytuację gdzie projektujący dany kawałek aplikacji nie myśli się poprzez realizowane funkcje a przez sam kod. Niestety tutaj można spotkać taką samą sytuację i tak np. w sklepie internetowym możemy spotkać kilka klas obsługujące koszyk w zależności od punktu dotarcia do niego użytkownika… czy np. w systemie rezerwacji każdy typ biletu posiada własną reprezentującą go klasę…  – już na pierwszy rzut oka wygląda to na pomyłkę.

Oba przypadki zarówno skrajnego rozdrobnienia jak i niewłaściwego zaprojektowania „bytów” wynikają prawdopodobnie z niezrozumienia samego środowiska obiektowego i jego właściwości oraz wad, jakie niesie. Nawet znając SOLID’a bardzo łatwo jest doprowadzić do przerostu formy nad treścią i doprowadzić kod do sytuacji, w której z prawnej perspektywy będzie przypominał stare dobre lata 80-te i programowanie proceduralne… może nawet będzie można spotkać w nim kilka instrukcji GOTO ;)

Jak uniknąć takich sytuacji, przy założeniu, że mamy podstawową podręcznikową wiedzę na temat SOLID i SRP? Odpowiedzią są 3 zasady:

Pierwsza zasada – myśleć :) pierwsza i podstawowa zasada  – SOLID od tego nie zwalnia. Myśleć, zbierać doświadczenie i cały czas myśleć…

Druga zasadę sformułował dawno temu znany naukowiec – „Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze.”  A. Einstein

Trzecia - zasady – nawet SOLID są po to żeby je łamać :)

Osoby zainteresowane SOLID, które nie słyszały o tym podejściu odsyłam do google czy binga – w sieci jest bardzo dużo materiałów na ten temat. Kilka wybranych przeze mnie linków znajdziecie poniżej.

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://mmiika.wordpress.com/oo-design-principles/

Tagi: , , , ,

agile Brak komentarzy, możesz być pierwszy »