17 paź 2008

OO

Dobrze pamiętam 2 rok studiów. Przedmiot: Programowanie Obiektowe. Język: C++. Projekt na zaliczenie: Komisariat Policji. Trzeba było zrobić 5 klas na krzyż wykorzystać słowa kluczowe virtual, friend, protected i miało się ocenę. Normalnie ekstra.
Ale jednak teoria była dość jasna. Książka do tego pewnie jakaś była (nawet nie pamiętam czy była...) i generalnie człowiek uwierzył, że tak się pisze oprogramowanie (choć przez wcześniejsze dwa semestry wmawiali co innego...)

A potem poszedłem do pracy. A tam servlety (tak, tak, wtedy pisało się servlety...), JSP, Struts i z dnia na dzień okazało się, że jednak nie. Że kod realizujący funkcje oczekiwane przez klienta pisze się we frameworku. To daje ogromne możliwości. Po pierwsze szybko się pisze - wystarczy podziedziczyć (mówiłem, że OO) po klasie Action. Po drugie framework daje Ci wszystko czego możesz potrzebować. Tak czy siak cała moja nauka o OO na którą pracował stolarz w Radomiu, piekarz w Ciechanowie i pucybut w Galerii Mokotów (no i pewnie jeszcze paru innych podatników) poszła na marne.

Ale do rzeczy. Bo może jednak nie poszła. To będzie takie mini przypomnienie absolutnych podstaw OO. Przeczytaj i zastanów się jak aplikacja, nad którą aktualnie pracujesz ma się do tego.

Kod aplikacji powinien być w obiektach. Nie w akcjach. Nie w komendach. Nie w managerach. Ani nawet nie w Session Beanach EJB3. Tylko w obiektach. Dokładniej to w klasach, bo java realizuje obiekty wyłącznie poprzez instancje klas, więc powiedzmy, że w klasach. (Martin Fowler nazwał je POJO w odróżnieniu właśnie od klas związanych ze wszelkimi wzorcami, frameworkami, platformami itp.)

Poza skrajnymi przypadkami każda aplikacja powinna być rozpoczynana od modelowania (tak, to jest agile - przypomnę, że słówko "agile" nie oznacza "bezmyślnie", tylko "sprawnie" - sprawniej jest pomyśleć i potem zrobić niż zrobić i sprawdzić czy a nuż działa). Czyli wymyślenia obiektów które będą realizowały funkcje aplikacji poprzez wzajemne relacje i przekazywanie sobie komunikatów. Czyli zanim zaczniesz pisać kod musisz wiedzieć jak wygląda twój świat. Jakie są w nim elementy. Jak mogą się komunikować. Nie do najdrobniejszych szczegółów. Ale tak, żebyś wiedział co piszesz i dlaczego.
A teraz spójrz na swoją aplikację i sprawdź jaki procent jej wymagań funkcjonalnych jest zrealizowanych wewnątrz klas reprezentujących dziedzinę twojej aplikacji.

To jest nie tylko kwestia praktyk czy podejścia. To kwestia profesjonalizmu. Odpowiedzialności. Nawet etyki zawodowej.
Jeżeli aplikacja ma żyć dłużej niż rok to jakiekolwiek wiązanie funkcjonalności aplikacji z jakimś frameworkiem/platformą/biblioteką jest marnowaniem pieniędzy klienta.
Ale jeśli nawet nie wiążemy się z żadnym frameworkiem (tajna broń EJB3) ale aplikacja nie ma przejrzystych obiektów dziedziny a zamiast tego funkcjonalności ukryte w komendach/managerach/fasadach/akcjach itp. To i tak ryzykujemy pieniędzmi i czasem klienta (czas wdrożenia nowych programistów będzie znacząco większy). Czy ktoś daje nam do tego prawo?

Brak komentarzy: