Saturday, February 23, 2013

Obiektowo orientowana pogoń za własnym ogonem

W tym poście. Sławek napisał komentarz:

W tym wszystkim brakuje mi jednej rzeczy, bez której refaktoryzacja przypomina szalony bieg z tasakiem. Refaktoryzacja do czego? Nie do wzorców, nie do SOLID, nie do Clean Code...

Do postaci, która oddaje zrozumienie problemy (dziedziny). Z moich obserwacji tego właśnie brakuje, ten i problem w pewnych klasach systemów próbuje rozwiązać DDD.

(...)


Zacząłem odpisywać i się rozpisałem, wiec przerzucam do posta.

A wiecie, że w systemach a'la Oracle Forms, bez obiektowej warstwy aplikacyjnej, rzadko występują problemy właściwe systemom, w których się tę warstwę wepchnęło? Z pewnością widziałem mniej systemów niż niektórzy z czytelników, trochę jednak widziałem, i takich i takich.

Nie trzeba zastanawiać się nad rozszerzalną (czy to cokolwiek sensownego znaczy?) architekturą, bo architektura jest mocno narzucona; nie trzeba kombinować jak uzyskać możliwość szybkiego wdrażania, bo mamy to prawie out of the box.

Programiści PL/SQL raczej nie narzekają na jakość kodu, wydajność, złożoność przypadkową i intencjonalną. Radzą sobie. Czasem nawet dziwią się, że w OO-świecie są tego typu problemy. Już słyszę obiekcje, że OOP nadaje się do dużych systemów. Akurat te największe, z którymi miałem do czynienia, były db-centric.

Być może ludzie wymyślili DDD, frameworki (sygnalizowałem to wcześniej) inne takie tam tylko po to, aby poradzić sobie z problemem, który sami wygenerowali wymyślając OOP. Po co więc brnąć w coś i rozwijać metody, skoro to coś samo w sobie zostało oparte na niewłaściwych (zbyt skomplikowanych) założeniach?

Dalej, logiczna prostota (i idące za tym ograniczenia) technologii typu Forms, sprawia że łatwiej skonkretyzować oczekiwania użytkowników. Dlaczego? Bo technologia z góry narzuca, co jest dozwolone, a co nie jest i nie pobudza fantazji zbyt wieloma opcjami do wyboru. Może i działa to nieco odwrotnie: oto już IT nie "modeluje" świata biznesu, lecz daje biznesowi parę formatek, nazwy pól, a biznes sobie projektuje co i jak ma działać.

Co właściwie, wymienione na początku DDD próbuje rozwiązać (mowa tu o tej części książki, w której mamy bloki budujące)? DDD chce stworzyć koncepty, dzięki którym będzie można łatwiej opisywać rzeczywistość i jednocześnie przekładać ten opis na model obiektowy. Trochę nadużywamy słowa "model". Model to model - opis działania rzeczywistości taki jak np. poniższy. Same prostokąciki, strzałki, napisy itd. Tak jak na rysunku.



Teraz ten model można przenieść do świata IT na wiele sposobów. Można za pomocą obiektów (co robi DDD), można przełożyć na związki encji, nawet na pliki - wszystko jedno. DDD to tylko narzędzie do przekładania modelu do IT w jakiś specyficzny sposób. DDD to tylko jedna możliwości. Czy aby na pewno OOP jest najprostszym sposobem na przenoszenie modelu do IT?

Prócz standardowego trójkąta projektu, zespół podlega jeszcze jednemu ograniczeniu: kompetencje programistów. Gdybyśmy w każdym zespole mieli samych Ericków Evansów, to w warstwę aplikacyjną, OOP, DDD można wchodzić w ciemno. Najczęściej jednak raz na jakiś czas zdarzy się jakiś "quasi-Evans", a większość to jednak Janowie Kowalscy.

Jakiś czas temu, 60-letni uczestnik szkolenia Wzorce Projektowe. Powiedział: "Nie bardzo rozumiem, po co te wszystkie klasy? Kiedyś to, co się pisało, trzeba było porządnie nazwać i to zazwyczaj rozwiązywało problemy" I o to chodzi: grunt to prostota.