mój pierwszy post - na głęboką wodę :D

Od dziś bloga mam i ja :D Nosiłem się z myślą publikowania takowego już od dawna i nawet założyłem konto na blogspocie. Leżało jednak wiele miesięcy odłogiem czekając, aż wpadnę na pomysł jak i o czym pisać :).

Zatem.. z całą pewnością tematyka będzie ściśle związana z moimi zawodowymi zainteresowaniami ( czyli informatyka - inżynieria oprogramowania ), a może i z czasem przyjdzie mi ochota na offtop'owanie w kierunku prywatnym :P. Coby nie było, że my informatycy tylko o jednym ;)

Prawdę mówiąc natchnieniem do napisania pierwszego postu był pomysł, na który ostatnio wpadłem pisząc projekt w ramach kursu akademickiego. Wiąże się z domain driven design, a dokładniej specyficznym podejściem DDD do implementacji (powiedzmy domain-centric design :) ). Z grubsza można powiedzieć, że chciałbym wykorzystać wzorzec Special Case [Fowler2003] w taki sposób aby podmiana implementacji odbywała się automatycznie. Najlepiej tłumaczy się na przykładach, więc poniżej przykładowe wykorzystanie kodu:

 User u = User.findUser("pawel");
 // nie ma w bazie, zwraca instancję UknownUser
 assert "pawel".equals(u.getName());
 // jest imie dla UnkownUser
 assert !u.isRegistered();
 // ale uzytkownik nie jest zarejestrowany
 u.register();
 assert "pawel".equals(u.getName());
 assert u.isRegistered();

1. Użytkownik "pawel" nie został odnaleziony w bazie, więc zwracana jest instancja UnkownUser (wariacja na temat NullObject, specjalny przypadek SpecialCase). Zignorujcie manierę ActiveRecord, to nieistotny szczegół ;)
   
2. Użytkownik posiada dane...
   
3. .. ale nie jest zarejestrowany (de facto nie istnieje !)
   
4. Dokonywana jest rejestracja na obiekcie klasy UnkownUser, która powoduje, że w tym momencie obiekt "u" jest już de facto instancją klasy RegisteredUser (kwestia nazewnictwa nieistotna).
   
5. Ta i następna metoda jest wywoływana w kontekście klasy RegisteredUser. Należy więc zakładać, że nie nastąpiła jakakolwieka zmiana stanu instancji klasy NullUser o której wspomniałem wcześniej.
6. P.w.

Sądzę, że w tym momencie jest już jasne co miałem na myśli mówiąc o podmianie implementacji :) Nazwa wynika stąd, że gdyby taka konstrukcja była możliwa, możnaby to zrobić przez:
this = new RegisteredUser().

Naturalnie jest to jedynie przykład ułatwiający zrozumienie tematu, jako że wybór konkretnej implementacji jest na tym etapie nieistotny. Sądzę, że ważna jest natomiast ekspresywność rozwiązania. Pozwala na bardziej dokładne zamodelowanie dziedziny, zwłaszcza w przypadku obiektów, które w cyklu życia zmieniają swoje role (a więc także i zachowanie).

Zdaję sobie sprawę, że powyższy problem można rozwiązać na wiele innych sposobów (np. zwracać instancje nowych ról z odpowiednich metod). Ciekawi mnie jednak czy istnieją już podobne do powyższych rozwiązania i na ile mogłyby się one sprawdzić w praktyce. Wierzę, że istnieję więcej zalet ( i pewno wad ;) ), które wyszłyby na jaw przy bardziej dogłębnym potraktowaniu tematu. Być może w chwili wolnego zajmę się Proof of Concept ... ;)

Bibliografia:
1. [Fowler2003] Martin Fowler, "Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe.", Addison-Wesley 2003