– Cześć, Amigo! Chciałbym opowiedzieć Ci dziś o kolejnej zalecie OOP. Widzisz, programy bardziej przypominają zwierzęta niż budynki. Nie są budowane, tylko rosną. Rozwój oznacza ciągłe zmiany. Kiedy stawiasz budynek, masz konkretny plan i realizujesz go według ścisłych wytycznych. Podczas tworzenia oprogramowania jest inaczej.

Bardzo często nie możesz czegoś zrobić tak, jak zamierzałeś i musisz dużo zmienić w swoim programie. Jeszcze częściej zdarza się, że to klient wymaga od Ciebie wprowadzenia pewnych zmian.

– A jeśli klient dostarczy naprawdę szczegółową specyfikację?

– Pomyśl, co dzieje się wraz z upływem czasu. Jeśli produkt odnosi sukces, klient chce wypuścić nową wersję, a potem kolejną i kolejną. A Ty, oczywiście, musisz dokonać kilku «niewielkich zmian» w tym produkcie. A zatem tworzenie oprogramowania to długa seria zmian wprowadzanych w różnym tempie. Nowa wersja może być wypuszczana co tydzień, miesiąc bądź co pół roku.

Java university

– Jaki z tego wniosek?

Wewnętrzna struktura danego produktu musi być tak skonstruowana, aby pozwalała na dokonywanie dużych (i małych) zmian przy jak najmniejszej liczbie poprawek.

– Ale jak to zrobić?

– Niedawno rozmawialiśmy o tym, że program składa się z obiektów, które na siebie oddziaływają. Obiekty naszego programu przedstawimy na tablicy przy użyciu dużych kropek. Narysujemy strzałki od jednego obiektu (kropki) do wszystkich obiektów (kropek), z którymi wchodzi on w interakcje.

A następnie połączymy obiekty (kropki) w grupy. Kropki należą do tej samej grupy wtedy, kiedy mają więcej połączeń ze sobą nawzajem niż z innymi kropkami. Jeśli większość strzałek wychodzących od danej kropki wskazuje na kropki w jej grupie, to znaczy, że obiekty zostały pogrupowane poprawnie. Kropki wewnątrz tej samej grupy są ze sobą ściśle połączone, natomiast kropki z różnych grup połączone są luźno.

To zjawisko nazywa się «zasadą luźnego powiązania». Program dzieli się na wiele części, często warstw, których logika jest ściśle powiązana z ich wewnętrzną strukturą i luźno powiązana z innymi warstwami/częściami. Interakcja między warstwami jest zazwyczaj mocno podzielona. Jedna warstwa może wywoływać inną warstwę przy użyciu tylko małego podzbioru jej klas.

– To ta sama zasada co przy „podziale pracy”, ale na większą skalę?

– W rzeczy samej. Pozwala nam to reorganizować dział, zwiększać jego wydajność i zatrudniać więcej ludzi, ale jeśli nie zmienimy organizacji współpracy między działami, to wszystkie nasze zmiany nie wyjdą poza lokalny poziom. Nikogo nie trzeba przekwalifikowywać. Nie musimy zmieniać całego systemu. Każdy dział może zoptymalizować w odpowiedni sposób swoje wewnętrzne sprawy, o ile tylko dobierze właściwie mechanizmy interakcji między działami.

– Jeśli dobierze je właściwie... A jeśli nie?

– To wtedy tracisz «pole manewru» na dokonywanie zmian i musisz zmieniać cały system. To się czasem zdarza. Nie możemy przewidzieć przyszłości, ale możemy zminimalizować to, ile razy będziemy musieli ponownie pisać program.

– Dobrze. Rozumiem zalety dzielenia programu w ten sposób, ale jak to się ma do OOP?

– Kiedy podejmujemy decyzję, w jaki sposób zorganizować działy i jak będą one na siebie oddziaływać, stosujemy „zasadę abstrakcji”. Abstrakcji w programowaniu używa się, aby ustalić najlepszą metodę dokonania podziału programu i sposób oddziaływania między jego częściami. Ta zasada może być wielokrotnie stosowana w stosunku do jego części składowych, do czasu aż rozbijemy program na osobne klasy.

– A ukrywanie wewnętrznej struktury tych części i sztywne ograniczanie ich interakcji z innymi częściami to enkapsulacja, prawda?

– Dokładnie. Enkapsulacja i abstrakcja to filary OOP. Dobry program musi przestrzegać tych dwóch zasad. Później przyjrzymy się innym zasadom oraz ich zaletom.

– Brzmi dobrze. Już nie mogę się doczekać!