Część 0
Część 1
Część 2
Część 3
Część 4
Część 5
Część 6

Z głośników benefis Marka Niedźwieckiego. Na blogu siódma zasada Jeff’a Bay’a:

Nie używaj klas o więcej niż dwóch polach

Na początek kilka wyjątków, ponieważ ta zasada jest dość ciekawa. Otóż do liczby pól w klasie nie zaliczamy serialVersionUID oraz cache dla hashCode i toString. Pierwsze z wiadomego powodu – być musi jeżeli klasa jest serializowana. Reszta być może jeżeli klasa będzie niezmienna – pola będą final i obiekty w tych polach też będą niezmienne.

Teraz do rzeczy.

Ile masz rąk?

Zazwyczaj odpowiedź brzmi dwie. Nawet jeżeli jesteś „code monkey” to nadal nie posiadasz ani chwytnych stóp ani ogona. Zatem jesteś wstanie wykorzystywać tylko dwa przedmioty na raz.

Co z klasami modelującymi dane?

Zdawać by się mogło, że zasada ta nie jest do zastosowania wobec klas, które modelują dane (jakie to klasy? W uproszczeniu te które zawierają adnotacje JPA). Szybko można jednak dojść do wniosku, że i tu mamy pole manewru. Poza klasami posiadającymi tylko jedno pole – zasada numer 3 i zasada numer 8, są jeszcze klasy, które mają za zadanie komponować klasy zawierające po jednym polu. Jeżeli taka klas będzie miała dwa pola to będzie dość.

Po co?

Ok po co to robimy. W przypadku obiektów biznesowych intencja jest jasna. Im mniej pól, tym mniej wykonywanych operacji i tym samym ściślejsza odpowiedzialność.
W przypadku obiektów DTO sprawa ma się trochę inaczej. Na pewno każdy prędzej czy później trafi na obiekt, który ma wiele(10+) pól i współpracuje z innymi obiektami o podobnym rozmiarze. Jest to często spotykany przypadek w starym kodzie. Prześledzenie w jaki sposób przekazywane są poszczególne wartości. Jak wygląda współpraca między nimi, co jak i dlaczego jest przekazywane. Znacznie prościej jest zatem zdekomponować klasę i otrzymać znacznie prostszy w ogarnięciu kod. Nie ma wtedy miejsca na zastanawianie się, które z dziesięciu pól do czego służy. Jesteśmy za to prowadzeni jak po sznurku od elementu do elementu.
Ostatnią istotną cechą tak stworzonej hierarchii obiektów jest bardzo proste sprawdzanie poprawności stanu całego zestawu. Każdy z elementów ma własny walidator, który można odpowiednio przetestować, ma własny zestaw testów, ma w końcu jasno określony cel. Dodatkowo łatwo jest też „uniezmienniczyć” obiekty wystarczy dodać kilka razy final.

Podsumowanie

Problematyczne na pierwszy rzut oka wydaje się wykorzystanie tej zasady w przypadku wykorzystywania ORM. Ostatni mój projekt poprowadzony zgodnie z tymi zasadami używa JPA2. Na początku było dziwnie. Teraz jest dobrze. Grunt to poznać zasady mapowania w JPA2. Szczególnie jak mapować klasy złożone. Szczególnym przypadkiem wykorzystania tej zasady są naturalne klucze główne, które ze swej natury organizują kod w mniejsze klasy o lepiej określonym przeznaczeniu.
To tyle. Za niedługo trzeba będzie pokazać kawałek kodu 😀