Object Oriented czy jedynie Class Oriented?

Dziś będzie o "nowym" podejściu do Object Oriented.
Jeżeli komuś wydaje się, że już nic nowego nie można w tym jakże oklepanym temacie dodać, to zachęcam do zapoznania się prezentacjami zawartymi w tekście. Dowiecie się również dlaczego nowym napisałem w cudzysłowie.

Od jakiegoś czasu z wielu stron pojawiają się zachęty do zainteresowania się nowymi językami, takimi jak Scala, Groovy, Ruby,...

Do tej pory wszyscy orędownicy pokazują jak to fajnie można sobie operować na kolekcjach (sortować, wyszukiwać) w jednej linijce kodu dzięki możliwości "doklejania" nowych metod do istniejących klas. Z całym szacunkiem, ale jest to nic innego jak objaw onanizmu technicznego. Jeżeli mam zainteresować się nowym językiem tylko po to aby uniknąć klepania pętelek to jednak zastosuję "cwanego" utilsa. Czy aby na pewno nowe języki powstają tylko po to aby sobie dokleić do klasy String 100 nowych metodek, o których istnieniu wie tylko doklejający?

Jeszcze inni odkryli ponownie możliwość dynamicznego dodawania "w locie" do encji metod zapisujących i wczytujących je. Myślałem, że niesławny Active Record odszedł już dawno w niepamięć. Ale jednak nie - okazuje się, że jest sexi w niektórych frameworkach.

Podczas niedawnej sesji researchu trafiłem na ciekawą koncepcję, która nadaje prawdziwy i pragmatyczny sens tym wszystkim konstruktom językowym.Pojawił się oto "nowy" paradygmat programowania: Data Context Interaction, który wskazuje zastosowanie dynamicznych konstruktów do lepszego (a przynajmniej innego) modelowania problemów. Czyli mamy coś więcej niż sortowanie listy, mamy nową jakość myślenia o modelowanej strukturze.

Twórcy DCI twierdzą, że mainstreamowe podejście do OO to jedynie kilka % prawdziwego OO. Klasyczne podejście skupia się na klasach, czyli na pewnych strukturach. Stawiają oni klasycznemu podejściu zarzuty, że skupia się ono na klasach zamiast na obiektach, co jakoby powoduje "rozsmarowanie" logiki Use Case po wielu klasach, dzięki czemu w nietrywialnych aplikacjach z czasem coraz ciężej przychodzi połapanie się w logice.

Czy zatem czas na powrót do paradygmatu proceduralnego, gdzie mamy cały "flow" w 1 miejscu?
Niekoniecznie.
Spójrzmy ma poniższy rysunek:


źródło: http://www.underbjerg.com/2009/11/16/oredev-2009-impressions-and-dci-architecture/

Dane opisują przy pomocy Klas pewną niezmienną strukturę - można powiedzieć core modelu (może mieć on pewne bazowe, ogólne zachowania).
Interakcje są wyniesieniem zachowania do poziomu głównych bytów, dzięki czemu lepiej odpowiadają modelowi mentalnemu usera. Są pewnymi rolami, które mogą być przyjęte przez obiekty. Interakcje operują na Danych ponieważ są do nich mixowane w...
Kontekście - kontekst odpwiada Use Caseom lub ich krokom. To w pewnym kontekście dane są łączone z rolami (zachowaniem) tworząc dopiero obiekty.

Intuicyjny przykład: jestem człowiekiem, opisuje mnie zestaw standardowych parametrów. Ale w zależności od kontekstu przyjmuję niektóre role (a wraz z nimi zachowania): Programista, Manager, Ojciec, Kierowca, Gracz, Klient, ...


Jeżeli udało mi się chociaż trochę zainteresować Was koncepcją DCI (nie mylić z nieco mniej innowacyjnym CDI;) to polecam następujące materiały:

- Architektura i ciekawy przykład w Ruby - aby zaintrygować dodam, że znajdziecie tutaj ostrą krytykę TDD.
- Ciekawe podejście do modelowania - mamy tutaj przykład niesamowitej jasności myślenia i pokaz tragikomicznego frameworka Qi4j (Java się jednak nie nadaje do DCI)
- Niezbyt porywające wprowadzenie teoretyczne - z którego dowiemy się, że te koncepcje mają już kilkadziesiąt lat, tylko gdzieś się zapodziały w przemyśle.
- Niekoniecznie świadome DCI w Scali - plus durne przykłady sortowania kolekcji;)


Ogólnie polecam materiały z konferencji Øredev - jak widać tematyka jest jest bardzo ciekawa i mocno wykracza poza mainstream.

A w inkubatorze (póki co) Eclipse mamy coś bardzo podobnego: Object Teams


//==========================

Ciekawie DCI podsumował jeden ze znajomych architektów (przy okazji "snajper", który potrafi trafić człowieka z granatnika z odległości całej planszy w Modern Warfare 1): "ale trzeba mieć jaja aby zakwestionować standardy i przedstawić coś tak odmiennego".

Programiści Enterprise nie gęsi i swój język mają

Zastanawialiście się kiedyś nad alternatywną składnią języka waszej matki? Na przykład taką, w której nie ma słowa być?

Jak to nie ma być? Przecież to podstawa? Da się w ogóle coś w nim powiedzieć? I po co się wydurniać? Przecież jestem w stanie się dogadać w sklepie i kupić sobie bułki więc jest git! I telewizor też jestem w stanie zrozumieć mogę też!

Jeżeli ktoś zdołał w sobie stłumić reakcję obronną przed dysonansem kognitywnym i temat wydał mu się intrygujący to warto zapoznać się z ideą języka E-Prime (ciekawe wprowadzenie tu: "Język E-Prime (English Prime) powstał jako swoisty dodatek do teorii niearystotelesowskiego systemu semantyki ogólnej autorstwa Alfreda Korzybskiego..."). Języka, który wręcz zachęca do formułowania subiektywnych wypowiedzi zależnych od kontekstu.

Znowu okazuje się, że to co wydaje się być naturalne, oczywiste i bezdyskusyjne jednak takie nie jest - niektórzy filozują nawet na takie, jak by się wydawać mogło, dawno zamknięte tematy. Oczywiście nie chodzi mi o to by od razu przestawiać się na nowy sposób mówienia i myślenia - po prostu nowe spojrzenie może otworzyć nową furtkę, przez którą ma szansę wedrzeć się struga świeżego powietrza rozrzedzając nieco stęchliznę.

Tyle tytułem wstępu - czas na mięcho...

Języki programowania ogólnego przeznaczenia wywodzą się z języków tworzonych na potrzeby matematyków. Przecież każdy "dinozaur" kodujący w szalonych latach 60 jest w stanie rozczytać kod klasy Javy, C# czy czegokolwiek co jest podobne do C.
Bo cóż takiego mamy do wyboru? Parę konstrukcji iteracji, parę konstrukcji selekcji, sekwencję oraz zestaw operatorów arytmetycznych. W starszych językach mogą być jeszcze technikalia związane z niskopoziomowymi szczegółami takimi jak zarządzanie pamięcią;)

/*
Żeby nie było, że należę lub sympatyzuję z nielicznymi (ale jednak) bezrefleksyjnymi i nieświadomymi niczego koderami, którzy twierdzą, że wszystkie języki programowania są takie same i są w stanie nauczyć się w ciągu paru dni dowolnego języka. Nie; chodzi mi po prostu o możliwość przeczytania kodu a nie o świadome jego tworzenie.
*/

Zatem praktycznie nie istnieje wsparcie dla logiki biznesowej w mainstreamowych językach (w niszowych nie wiem bo nie inwestygowałem). Jedyne co mamy to klasy, interfejsy, metody, pola i rozszerzanie (specjalnie nie piszę dziedziczenie, bo bez cech regresywnych nie ma co mówić o dziedziczeniu). Do tego instrukcje sterujące, operatory i radź sobie.



Od jakiegoś czasu przyglądam się Czi (przy okazji warto nadmienić, że Ojcem Założycielem jest nie byle kto, bo jeden z założycieli JBossa Rickard Öberg). Pora wrzeszczcie napisać coś bardziej konkretnego - najlepiej co nowego i dobrego to wnosi.

Qi ma szansę wypłynąć na fali rosnącej popularności Domain Driven Design. Widać, że swego rodzaju prąd myślowy DDD elektryzuje coraz większą grupę developerów. Będą oni w wkrótce potrzebować nowego frameworka wspierającego DDD aby wyżyć się w nowej przestrzeni.

No dobra, jak Qi wspiera DDD?
Przede wszystkim w Qi zachowanie (odpowiedzialność) zależy od kontekstu. Czyli idziemy bardziej w stronę świata rzeczywistego, w którym ta sama osoba może być w zależności od sytuacji programistą, mężem, motocyklistą...

Qi rozszerza standardowe "figury składniowe" o:

• Mixins: Containing state, e.g. Name, Person, Adress
  
• Concerns: Statelessm e.g. TransactionWrapper, Security
  
• Constraints: Checking parameters, e.g. NotNullConstraint
  
• SideEffects: Managing side effects, e.g. sending Mail
  

Oczywiście jest to rozszerzenie nieingerujące w składnię Javy 5 ponieważ opiera się na adnotacjach.

Jednym z głównych założeń Qi jest maksymalna reużywalność kodu. Jak wiadomo prawdopodobieństwo ponownego użycia rośnie gdy kod jest odpowiedzialny za jedną maksymalnie koherentną rzecz. Zatem w Qi składamy (komponujemy) wymienione powyżej fragmenty w większe części - kompozyty. Składanie kompozytów z części pozwala na zmianę ich zachowania - możemy zawsze spojrzeć na kompozyt z perspektywy jednej z części. Przykładowo możemy pozbyć się niezręczności wynikającej z "podczepienia" encji zawierającej metody biznesowe pod GUI. Po prostu w kontekście GUI encja jest np "prezenterem".

Qi zgodnie z DDD zakłada, że logika biznesowa jest aspektem, na który należy położyć największy nacisk, zatem zadaniem frameworka jest automagiczne przejęcie odpowiedzialności za technikalia takie jak persystencja czy transakcje. Pozwala to skupić uwagę na prawdziwym problemie stanowiącym rzeczywistą wartość systemu podczas gdy inne frameworki skupiają się jedynie na rozwiązywaniu problemów technicznych (zwykle przykrywając je kolejną warstwą abstrakcji zgodnie z zasadą Davida Wheelera "Any problem in computer science can be solved with one additional layer of indirection.").

Od strony technicznej QI zasadza się na AOP i IoC (DI w szczególności).


//====================


W sumie to sprytne stosowanie składni "subiektynej" (bez być) i "obiektywnej" (z być) jest jednym z głównych trików NLP czy w szczególności technik perswazji.

Przeglądając fora natknąłem się na krytykę Qi. Krytycy twierdzili jakoby twórcy Qi wzięli się za implementację swego pomysłu w nieodpowiednim języku. W skrócie: Java śmierdzi, Ruby jest sexi (heh żenada, język programowania jest sexi). Twórcy jednak ripostują:
- Composite Oriented Programming jest ideą, którą można zaimplementować w dowolnym języku
- Java jest standardem przemysłowym, posiada ugruntowaną pozycję i ogromne wsparcie społeczności.

I jeszcze jedno... kiedyś gdy miałem trochę zbyt dużo wolnego czasu zaczynałem nieśmiało zabawę z Pythonem i Ruby. O ile kojarzę to Ruby szczególnie charakteryzował się składnią, która jak teraz widzę mocno sprzyja COP. Szkoda, że autorzy tutoriali ograniczyli się do pokazania bzdurnych przykładzików prezentujących udziwnioną składnię nie pokazując, że nadaje się ona do implementacji idei szerszej niż tylko "hurra mój kod jest prawie tak paskudny jak bym go pisał w Perlu". A może sami wtedy jeszcze nie wiedzieli, że stworzyli potworka, który wspiera COP ;P

Dobrze gada, polać mu wódki

Wróciłem właśnie z wakacji...
hehe bez obaw, nie będę zanudzał czerstwym sprawozdaniem z urlopu:)

Jednak zmęczenie podróżą nie pozwala mi na napisanie niczego poza wklejeniem linku do ciekawego posta o Composite Oriented (Qi w szczególności): Qi4J the next Java? Forget Scala.

//===========================
Myśli warte uwagi:
- wrzuty na Eckela:)
- business logic - kto programował komercyjnie i ma zdolność choćby do odrobiny refleksji ten pewnie rozumie, że to właśnie BL rozwala projekty (jeżeli jeszcze nie wersji 1.0 to na pewno w 3.0) i że wypasione GUI i baza w 5. postaci normalnej nic tu nie pomogą
- misterność i pomysłowość nie mają mają nic wspólnego z młotkiem

Czi oriented

Główną wadą OOP jest to, że nie jest w ogóle Object Oriented!

Jeżeli jesteś ciekawy, kto ma na tyle tupetu aby coś takiego napisać to zapraszam tu: http://www.qi4j.org/

Natrafiłem na ten wynalazek po zapisaniu się na grupę DDD gdzie jest lansowany przez paru uczestników.

O ile być może nie koniecznie warto od razu tworzyć w Qi nowy system, to na pewno można zaczerpnąć z niego parę odświeżających idei, koncepcji czy nawet wzorców.

//=======================
OOP nie jest OO - heh szczyt bezczelności;)
Mimo tego będę zgłębiał temat, więc z czasem spodziewajcie się nowych postów otagowanych "Composite Oriented Programming" albo "Qi".