6 lut 2009

Ekstremalna obiektowość

Kto mnie zna, wie, że jestem stuknięty jeśli chodzi o obiektowość. Tak od paru lat. Z każdym projektem w którym uczestniczę (ew. który przeglądam...) coraz bardziej. Od czasu kiedy stworzyłem parę lat temu klasę-potwora - półtoratysiąca linii, z których z 500 było w jednej metodzie i nie dane mi było tej Augiaszowej stajni posprzątać, z wszystkich rzeczy w programowaniu dbam najbardziej o zachowywanie zasady pojedynczej odpowiedzialności. Jeśli miewam w nocy jakieś koszmary, to dotyczą one zawsze refactoringu tej klasy :)

W związku z tym moim małym zboczeniem, z wielką ciekawością przeczytałem (parokrotnie) jeden z rozdziałów w książce, którą aktualnie mam na tapecie - The Thoughtworks Anthology. Rozdział nosi tytuł Object Calisthenics (można go gdzieś w necie znaleźć jako .doc). Jeff Bay proponuje w nim 9 reguł dotyczących tworzenia kodu (przykłady są w javie, ale większość reguł odnosić się może do w miarę dowolnego języka, szczególnie OO). Są to
  • Tylko jeden poziom zagłębienia na metodę
  • Nie używaj słowa kluczowego else
  • Opakowuj wszystkie prymitywy i Stringi (w klasy o specyficznej dla zastosowania nazwie)
  • Używaj tylko jednej kropki na linię
  • Nie skracaj nazw
  • Pilnuj wszystkie encje by były małe
  • Nie używaj klas o więcej niż dwóch polach
  • Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)
  • Nie używaj getterów/setterów/własności
Wow - pomyślałem. To jak tu w ogóle pisać? Ale Mr. Bay jest w swoim tłumaczeniu dość przekonujący. Wolałbym co prawda więcej przykładów w artykule, ale już samo przedstawione przez niego rationale przekonuje mnie do większości z tych stwierdzeń. Co więcej, większość z nich i tak bardzo często stosuję (opakowywanie kolekcji i prymitywów, jeden poziom zagłębienia, nieskracanie nazw), ale autor przekonuje, żeby stosować te reguły wręcz fanatycznie. 

Parę rzeczy jest pewnych: 
  • taki kod jest bardziej obiektowy (podział odpowiedzialności, właściwe opakowywanie, itp.)
  • taki kod jest bardziej testowalny (małe metody, proste testy - taki design sam się prosi o TDD)
  • taki kod jest bardziej reużywalny (łatwiej znaleźć wiele zastosowań dla małej metody o dobrze określonej odpowiedzialności niż dla metody, która robi pięć rzeczy)
  • taki kod sam się dokumentuje (krótkie jednoznaczne nazwy metod powodują, że kod się czyta prawie jak zwykły tekst)
  • trudniej zrobić a łatwiej wykryć błąd w metodzie o 5 liniach niż w metodzie o 500 (to akurat wiem dobrze)
Może więc jednak warto naciskać na obiektowość i doprowadzać ją do ekstremum. 

Mimo, że generalnie artykuł Jeffa Bay'a jest bardzo blisko moich własnych praktyk programistycznych, wydaje mi się on zbyt ekstremalny. Póki co do niektórych reguł (a raczej ich fanatycznego stosowania) jestem trochę sceptycznie nastawiony, szczególnie jesli wziąć pod uwagę, że nasz kod zależy czasem od zewnętrznych frameworków/bibliotek które nie pozwalają nam na pełną elastyczność (jak na przykład pogodzić takie rozdrobnienie, brak getterów i setterów itp. z np. mapowaniem hibernate'owym). 
Tak czy siak autor zachęca do zrobienia ćwiczenia: 1000 linii kodu napisanego trzymając się tych reguł. A że w poniedziałek i wtorek mam szkolenie poza Warszawą, przynajmniej połowę z tego wyrobię :)

Brak komentarzy: