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:

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.

8 myśli na temat “Ekstremalna obiektowość w praktyce – część 0

  1. Czekamy na mięso. 😀
    PS. Integrowałeś kiedyś Springa z Vaadinem i Liferay’em? Jeżeli tak, to jest to ciężkie do wykonania (albo ewentualnie – choć wiem, że teraz pewnie mało czasu masz – dałbyś jakieś wskazówki/arta/jakiś wycinek kodu?)?

  2. „Ekstremalna” to bardzo trafne określenie, „obiektowość” już niekoniecznie. Pachnie strasznym poszatkowaniem kodu, miliardem klas w średniej wielkości projekcie i rozwleczeniem wszystkiego tak, że nic nie da się znaleźć, ogarnąć ni zrozumieć. Zamiast ekspresywności dostajemy przerost formy. SOLID – super. Clean code – super. „Do one thing” – doskonale. Ale bez jaj…

    No, ale to takie pierwsze wrażenie. Chciałbym zobaczyć niebanalną, rzeczywistą aplikację, która rygorystycznie się do tego stosuje.

  3. @Tomek, może dziś wieczorem przysiądę. Co do Vaadin i Liferay to łazi to za mną już kolejny miesiąc i nie mam czasu się temu przyjrzeć.

    @Konrad, dlatego tak ważne jest opanowanie IDE. Oszczędzamy wtedy bardzo dużo czasu. Warto też pamiętać, że choć pojedynczy projekt będzie rzeczywiście dość duży, ale warto tu wprowadzić jakiś dodatkowy podział na podprojekty tak by poszczególne elementy współgrały ze sobą. Ostatnio napisałem w pracy taką małą duperelkę, która wołała WebServices. Rzecz w tym, że potrzebowaliśmy po drodze liczyć skróty z wiadomości. Wywaliłem do osobnego jara w sumie z pięć klas na krzyż, które to robiły (dwie implementacje dla SunJCE i BC) i udostępniłem chłopakom tego jara. U mnie w głównym projekcie też na zewnątrz poleciała konfiguracja Guice. W sumie mam trzy niewielkie projekty, które mogę swobodnie wymieniać.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax