Ekstremalna obiektowość w praktyce – część 5 – Nie skracaj nazw
Część 0
Część 1
Część 2
Część 3
Część 4
Dziś smutna, 20 rocznica śmierci Freddego Mercurego. Z tej okazji z głośników Queen, a na tapecie piąta z zasad Jeff’a Bay’a
Nie skracaj nazw
Każdy kto choć trochę interesował się zagadnieniem jakości kodu wie, że najlepszy kod to kod samo-dokumentujący się. Innymi słowy jeżeli czytamy jakiś fragment, metodę czy kilka metod, to bez zagłębiania się w niższe warstwy możemy na podstawie samej nazwy, czy szerzej sygnatury, metody określić mniej więcej co ona robi.
Z drugiej strony nikt nie lubi pisać długich nazw. Jest to niewygodne. Dlatego tak ważne jest opanowanie IDE. Dzięki temu bardzo łatwo będziemy wstanie dostać się do systemu podpowiadania nazw. To znowuż zaoszczędzi nam czasu. Jeżeli jeszcze dodatkowo zdefiniujemy własne szablony kodu to pisanie staje się czystą przyjemnością.
Liberum Veto!
Jeff Bay porusza jednak znacznie ważniejszy aspekt związany z nazewnictwem zmiennych, metod oraz klas. Jest to zniechęcenie, które pojawia się gdy wielokrotnie musimy powtarzać daną nazwę.
Czyli co? Skrócić nazwę?
I tak i nie. Jeżeli jakaś nazwa przewija się w kodzie wielokrotnie może to sygnalizować kilka problemów:
- Metoda jest przeładowana.
- Zgubiliśmy klasę.
- Źle określiliśmy zakres odpowiedzialności.
Metoda jest przeładowana
Oznacza to, że metoda wykonuje kilka rzeczy w zależności od wartości argumentów. Zazwyczaj na początku mamy kilka ifów, które pełnią rolę routera kierując przepływ sterowania w oparciu o jakąś wartość.
Rozwiązaniem jest rozdzielenie metody na kilka mniejszych i jeżeli istnieje konieczność zmiana w kodzie wywołującym tak by ograniczyć ilość instrukcji warunkowych. Warto też zastanowić się nad tym, czy dana operacja powinna być wykonana NA obiekcie czy raczej powinna być wykonana PRZEZ obiekt.
Zgubiliśmy klasę
Szczególnie widoczna przypadłość wszelkich klas Utils gdzie w ramach jednej klasy utrzymujemy wiele metod robiących wiele kompletnie nie związanych ze sobą rzeczy. Jeżeli w naszym kodzie dana klasa pojawia się często w różnych kontekstach warto rozbić ją na mniejsze bardziej wyspecjalizowane. Jeżeli nie jest to możliwe to należy pamiętać o adnotacji @Deprecated i wydelegować poszczególne grupy metod do osobnych klas. Zostaniemy w ten sposób z „klasą wydmuszką”, którą będzie można stosunkowo łatwo usunąć.
Źle określiliśmy zakres odpowiedzialności
Przypadek gdzieś pomiędzy wcześniejszymi. Z jednej strony dana metoda robi jedną rzecz, ale przy okazji wykonuje kilka dodatkowych czynności zazwyczaj związanych z walidacją parametrów czy sprawdzeniem stanu obiektu. W takim wypadku warto zastanowić się nad zmianą w kodzie tak by sprawdzać dane i delegować zadanie dalej albo założyć, że dane są zawsze dobre i nie ma sensu ich sprawdzanie.
Oba rozwiązania są poprawne, a wybór konkretnego zależy w znacznej mierze od przyjętej w ramach projektu konwencji oraz tego na jakim poziomie aplikacji jesteśmy.
Podsumowanie
Przestrzeganie tej zasady jest bardzo proste i powinno być naszym nawykiem. Dzięki niej nie tylko zyskujemy czas w trakcie czytania kodu, ale też możemy sprawnie identyfikować miejsca w kodzie, które wymagają poprawek. Co do zasady takie podejście sprawdza się w obu kierunkach. Jeżeli nie potrafimy nadać krótkiej i znaczącej nazw, która nie zawiera skrótowców to nasz kod wymaga poprawki.
Jak zawsze też w przypadku zasad Jeff’a Bay’a musimy uzbroić się w dobrą znajomość IDE. Bez tego będzie bardzo ciężko.