Monday 11 June 2012

Rozprawka o new i fabryce... fabryce fabryk faryk :)

To był mój powitalny post post na tym blogu, zawierał on sobie, niestety w formie obrazka, link do mojej odpowiedzi na stacku w temacie "Factory Design pattern and keyword 'new'".


Wracam do tego nie dlatego, że był to taki świetny wpis, który faktycznie nadawałby się na bloga, ale dlatego, że dziś przypomniałem sobie o nim, widząc ten obrazek:



Moim zdaniem świetnie oddaje on to o czym napisał  Joshua Kerievsky, którego cytowałem też tam, na stacku:
I’ve seen numerous systems in which the Factory pattern was overused. For example, if every object in a system is created by using a Factory, instead of direct instantiation (e.g., new StringNode(ノ)),the system probably has an overabundance of Factories.

Moja wypowiedź tyczyła się właśnie tego - chłodnej głowy w tworzeniu fabryk do wszystkiego. Fabryki fabryk fabryk. Bezsens. Z reguły używanie słowa kluczowego new przecież nikogo nie boli, mimo, że powstają całe poematy o tym "why 'new' is evil".

Przykładowy poemat - Java's new Considered Harmful - oczywiście, nie chodzi w nim o to, aby nigdy i nigdzie nie używać new, ale niestety niektórzy mają skłonności do zapędzania się i wtedy właśnie może powstać coś w stylu ProblemFactory.

... Nie chcę przepisywać tego, co już kiedyś napisałem na stacku, a co jest podlinkowane u góry tego posta, jak ktoś nie jest leniwy, to sobie kliknie :)



Po więcej odsyłam do wzorowego opisu wzorca fabryki wraz z opisem refaktoringu z nim związanego: Move Creation Knowledge to Factory. Warto, warto! Kiedyś zawodowo zajmowałem się czytaniem i pisaniem o wzorcach, ale ten artykuł, a w zasadzie fragment książki, to najlepsza rzecz o fabrykach, na jaką trafiłem. Polecam każdemu.


W sumie cała książka Joshuy jest jak najbardziej godna polecenia... i zarazem bardzo trudna do wygooglowania w formie pdfa :)





Na sam koniec jeszcze jedna perełka, luźno związana z tym o czym mowa powyżej - kiedy w zamyśle fajny design nie jest fajny, lecz jest problemem:

zle, i gorsze, pomysły na zamianę ifów na coś innego

jako morał można uznać jeden z komentarzy:


Pozwala to spiąć mój post słowami Atwooda, przytoczonymi wtedy na stacku:
The best way to learn to write simple code is to write simple code! Patterns, like all forms of complexity, should be avoided until they are absolutely necessary. That's the first thing beginners need to learn. Not the last thing.

Sunday 10 June 2012

FizzBuzz a TDD

Nim powrócę do pisania bardziej obszernych wywodów
(w kolejce są:
  1. dokończenie wywodów o skrótach klawiszowych w Eclipsie
  2. logowanie, Log4j, tail'owanie logów
  3. rozmowy kwalifikacyjne i zmiana pracy
)


Pora na coś lekkiego i przyjemnego Fizz buzz code kata:





Jeżeli komuś nic nie mówi ta nazwa, to odsyłam do artykułu Why Can't Programmers.. Program?




Fizz buzz code kata from Johannes Brodwall on Vimeo.

Zgadzam z późniejszymi słowami Atwooda, że każdy programista, który jara się programowaniem na tyle, aby czytać blogi poświęcone tej tematyce, już dawno jest w stanie poradzić sobie z FizzBuzzem... nie potrafię sobie wyobrazić choćby jednego znajomego z pracy, który mógłby mieć z tym problem.

Po co więc piszę o tym filmiku? Bo w namacalny sposób pokazuje on korzyści płynące z TDD. 30 minut pisania kodu i ani jednego system outa. Ani jednej niepewności czy nasz kod nadal działa, czy po refactoringu coś się nie wysypie. Jeżeli masz zamiar oswoić się z TDD, to moim zdaniem FizzBuzz powinien być pierwszą rzeczą jaką w nim wykonasz. Po pierwsze jest na tyle prosty, że wyniki i powód do zadowolenia są niemal od razu. Z drugiej zaś strony zadanie można rozwijać ugeneryczniając je w sposób podobny do zaprezentowanego na filmiku, co stwarza spore pole do popisu dla refaktoringu, ale nawet i bez tego jego złożoność jest wystarczająca, aby zacząć wpajać sobie zasadę (think-) red-green-refactor (polecam kliknięcie w linka, serio, fajny wpis).

Dodatkowo filmik obrazuje to o czym pisałem przy okazji porównania Eclipsa do notatnika - im bardziej potrafimy zmusić kompilator do pisania kodu za nas, tym lepiej!