Na początku każdego projektu jest spoko, kod jest mały i wszystko łatwo ogarnąć. Problemy zaczynają się, gdy kod zaczyna się rozrastać, zmiennych jest coraz więcej, a nam coraz trudniej połapać się o co we wszystkim chodzi.
W szczególności, gdy piszemy wszystko w jednym pliku, musimy pamiętać wszystkie zależności (a jest ich kwadratowo wiele, tak jak liczba wszystkich uścisków dłoni, także błędów też jest kwadratowo wiele)
Żeby wszystkiemu zaradzić i nie pogubić się, przychodzi na ratunek enkapsulacja. Z wikipedi: "Enkapsulacja(Hemrmetyzacja) polega na ukrywaniu pewnych danych składowych lub metod obiektów danej klasy tak, aby były one dostępne tylko metodom wewnętrznym danej klasy"
Co to więc dla nas znaczy? Naszym celem jest to, żeby moduły były ze sobą luźno powiązane.To znaczy, że każdy z komponentów jest zależny od jak najmniejszej liczby innych elementów. Dzięki temu możemy łatwo podmieniać elementy i łatwo je testować. Np. gdy mamy backend i frontend, to chcemy w tylko jednym miejscu opisać jak te dwa elementy są ze sobą połączone. Po co? A po to żeby móc rozwijać te dwie rzeczy osobno, niezależnie od siebie. Mowa oczywiście o testowaniu.
Ale wróćmy do naszej *enkapsulacji*, na której chciałbym się skupić. Dawniej, myśląc o tym, miałem przed oczami private i public w Javie, które ograniczają widoczność zmiennych na inne obiekty, ale to nie do końca jest najważniejsze. Enkapsulacja to jak dla mnie praktyka, którą powinniśmy się kierować pisząc kod. W każdym momencie powinniśmy zwracać uwagę na to kto ma dostęp do zmiennych/metod, które właśnie napisaliśmy. Jeśli w danym momencie, nasza zmienna opisująca adres serwera, jest dostępna w widoku głównym, to znaczy że robimy to źle. Zmienne powinny być widoczne tylko na takim poziomie na jakim jest to konieczne i nie możemy tego rozszerzać http://pastebin.com/FUbtkiqQ
Czemu to jest zrobione źle? Bo na głównym scopie, funkcja `cokolwiek` jest na tym samym poziomie abstrakcji co`ServerIP`, a to nie prawda Prawidłowo powinno być: http://pastebin.com/LaeLCPyY
Także podsumowując mój (bez)sensowny wywód - jak deklarujemy nowe funkcje/zmienne, zawsze róbmy to na jak najniższym poziomie, tak żeby jak najmniej innych elementów na danym poziomie widziało to co napisaliśmy. W ten sposób nasze funkcje będą małe, a my będziemy skupiali się na tym, że nasz kod to zlepek luźno powiązanych klocków, które można łatwo podmieniać.
Brak komentarzy:
Prześlij komentarz