Ekstremalna obiektowość w praktyce – część 0
Na Warsjawie Krzysztof Jelski i Paweł Lipiński poprowadzili warsztaty Obiektowa Gimnastyka. Celem było przybliżenie nam zasad przedstawionych przez Jeff’a Bay’a w książce The Thoughtworks Anthology. W rozdziale Object Calisthenics przedstawił on dziewięć zasad według, których powinniśmy tworzyć kod. Zasady te 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
Co ciekawe jeżeli poszukacie w sieci to znajdziecie dokument rtf z brudnopisem tego rozdziału, gdzie jest więcej zasad i są one trochę inne.
Do tych zasad dodaję jeszcze jedną:
Metody prywatne powinny być statyczne.
Wspominałem już o tej zasadzie przy okazji omawiania modyfikatorów, czas zatem zastosować ją w praktyce.
Będzie zatem kilka tekstów omawiających kolejno te zasady i demonstrujących jak stosować je w praktyce. Będziemy je stosować na kodzie z mojej prezentacji na Warsjawie. Zatem będziecie mieli okazję pobrać zarówno kod z prezentacji jak i zobaczyć co mnie tak zafascynowało w przedstawionej przez Krzyśka i Pawła metodzie tworzenia kodu.
Zasady nie są dla n00bów
Na początek ostrzegam, że zasady te nie są dla osób ledwo ogarniających programowanie. Wynika to z ich natury. Wymagają dobrego warsztatu zarówno od strony tworzenia kodu jak i metodyki pracy. Ponad to są trudne w zastosowaniu co powoduje frustrację nawet wśród doświadczonych.
Krótki test czy te zasady są dla ciebie:
- Masz swoje ulubione IDE i jest ono skonfigurowane pod ciebie?
- Umiesz przeprowadzić refaktoryzację kodu niezależnie od tego w jakim jest stanie?
- Stosujesz TDD na co dzień?
- Rozumiesz jak działają najpopularniejsze wzorce projektowe?
Jeżeli na trzy z tych pytań odpowiesz TAK to witaj na pokładzie. W przeciwnym wypadku wchodzisz na własne ryzyko.
Nie rzucaj się na głęboką wodę
Większość tych zasad nie nadaje się do stosowania „wprost”. Najwygodniej jest je stosować jako wskazówki do refaktoryzacji kodu i dokonywać tej refaktoryzacji zgodnie z tymi zasadami.
Jeżeli zaczniesz od razu pisać kod według wszystkich tych zasad to będzie to bardzo bolesny proces, w którym zwątpisz w swoje umiejętności. W dodatku jest to bardzo trudne do osiągnięcia ponieważ nie znam nikogo, kto byłby wstanie kodować bez zastosowania „dynamicznego projektowania”. Za to wiele osób nie potrafi pogodzić braku projektu z narzuconymi ograniczeniami.
Innymi słowy tak jak w przypadku wycinania skomplikowanego kształtu najpierw ciachamy „mniej więcej na oko” i potem docinamy tak i tutaj najpierw piszemy kod, który działa, a następnie docinamy go do wymagań.
Podstawa to IDE
Najlepiej skonfigurowane pod ciebie. Tak by jak najszybciej i najwygodniej jak to możliwe uruchamiać testy, szablony refaktoryzacji i skakać po klasach. Bez tego się nie obędzie.
Zatem zanim ruszysz z kodowaniem skonfiguruj i zaktualizuj IDE.
Na razie tyle. W kolejnym tekście mięso.