Naked Objects

Ostatnio moje zainteresowania programistyczne mocno oscylują wokół tematyki Domain Driven Design i przy okazji, jako że jest to temat dosyć pokrewny, natrafiłem na wzorzec zwany Naked Objects. W tym wpisie chcę przybliżyć główne założenia tego zagadnienia.

Wzorzec ten został opisany przez niejakiego Richarda Pawsona, który sporządził na ten temat swoją rozprawę doktorską. Postanowiłem więc sięgnąć do źródeł. Jak na każdą pracę doktorską przystało, również i ta Pawsona, stawia pewien problem, stara się odnaleźć jego genezę, proponuje rozwiązanie i rozprawia nad jego zaletami/wadami. W tym przypadku problemem jest niesławny anemiczny model - antywzorzec, który objawia się obiektami biznesowymi pozbawionymi odpowiedzialności rozsianej po procedurach. Pawson zauważa popularność tego antywzorca w aplikacjach enterprise dopatrując się takiego stanu rzeczy w niekontrolowanej ewolucji wzorca MVC. Można się zgodzić z taką genezą lub nie, ale fakt jest faktem, że problem istnieje. Proponowanym lekarstwem są właśnie Naked Objects.

Aby zrozumieć o co chodzi rozważmy poniższy rysunek:


Przedstawia on 4-warstwową architekturę aplikacji znaną chociażby z DDD, czy z UP, której sercem jest warstwa obiektów biznesowych (Domain object) odpowiadjących bytom, że świata rzeczywistego. Obiekty te nie są, w przeciwieństwie do anemicznego modelu, pozbawione odpowiedzialności i łączą w sobie własności i zachowania realizujące logikę biznesową aplikacji. W warstwie zwanej konrolerem znajdują się pogrupowane w klasy procedury, które realizują poszczególne use casey aplikacji delegując odpowiedzialność do obiektów biznesowych - NIE ZAWIERAJĄ tym samym logiki biznesowej. Z procedur tych korzystają komponenty widoku umieszczone w warstwie prezentacji. Oczywiście dane w aplikacji przeważnie muszą być utrwalane, chociażby w relacyjnej bazie danych - tym zajmuje się warstwa Data management. Każdy obiekt biznesowy ma jakieś odzwierciedlenie w każdej z tych 4 warstw, więc każda zmiana czy nowa koncepcja biznesowa oznacza zazwyczaj modyfikacje w każdej z warstw, czyli mnóstwo pracy. Rozwiązaniem może być uczynienie warstw widoku i kontrolera całkowicie generycznymi. Pawson proponuje ograniczyć się jedynie do implementacji modelu domeny biznesowej i generować UI z obiektów biznesowych. W rezultacie architektura naszej aplikacji zaczyna wyglądać następująco:


Wygenerowany interfejs użytkownika jest zorientowany obiektowo (OOUI - Object Oriented User Interface). Oznacza to tyle, że użytkownik widzi na ekranie odpowiedniki obiektów dziedziny, może przeglądać/edytować ich własności oraz wysyłać do nich komunikaty tj. wywoływać ich metody. W oczywisty sposób wymusza to, żeby obiekty biznesowe miały odpowiedzialność - bye bye anemic model. Jeśli komuś trudno sobie wyobrazić po tym opisie jak wygląda obiektowe UI, to dodam, że z takim GUI mamy do czynienia na co dzień użytkując współczesne systemy operacyjne - zarówno microshitowe jak i linuxowe z dowolnym środowiskiem graficznym. Obiekty są reprezentowane w nich poprzez ikony na pulpicie, które są abstrakcją aplikacji, sprzętu, elementów systemu plików, itp. Używając menu kontekstowego możemy przeglądać własności poszczególnych obiektów i wywoływać na nich różne akcje. Zauważmy, że tak samo może być w przypadku aplikacji enterprise - użytkownik aby zrealizować jakiś biznesowy use case musi odszukać na UI obiekt(y) które posiadają potrzebną odpowiedzialność, wyedytować ich własności i/lub wywołać jakieś akcje być może przekazując do nich parametry. Obiekty, które użytkownik widzi na ekranie mają oczywiście swoje odpowiedniki w warstwie domenowej, stąd właśnie nazwa wzorca Naked Objects - obnażone dla użytkownika obiekty dziedziny biznesowej.

Podstawowym zadaniem frameworków implementujących wzorzec Naked Objects jest zatem generowanie interfejsu użytkownika na podstawie obiektów warstwy biznesowej. Wystarczy wskazać, które obiekty mają być udostępnione użytkownikowi. Na rynku mamy kilka Javowych narzędzi tego typu. Jednym z nich jest framework stworzony przez firmę samego Pawsona i nosi tę samą nazwę co wzorzec, czyli Naked Objects. Inne darmowe toole to: JMatter (nie mylić z JMetter), Trails, Sanssouci, Domain Object Explorer. W najbliższym czasie postaram się przyjrzeć bliżej niektórym z nich i zamieszczę tutaj swoje wrażenia.

Podsumowując, do najważniejszych zalet Naked Objects należą:

• NIE anemiczny model dziedziny biznesowej,
• Znaczne zwiększenie szybkości developmentu - implementujemy 1 warstwę, resztę robi automat,
• Wspólny język pomiędzy developerami, a użytkownikami - kwestia mocno podkreślana w DDD,
• Moc OOP w interfejsie użytkownika.

Jako wady wymienić należy:

• Brak możliwości zmiany wyglądu generowanego UI, ktróry całkowicie zależy od frameworka,
• Użytkowanie OOUI może wymagać więcej nauki niż użytkowanie tradycyjnego use case driven UI.

Powyższe wady i zalety wskazują, że wzorzec Naked Objects może być stosowany tylko wtedy, gdy nie ma absolutnie żadnych wskazań do ręcznego tworzenia UI i użytkownik końcowy będzie długotrwale korzystał z aplikacji.