🚀 go-pugleaf

W bardzo ciekawy sposób przedstawił Pan swoje stanowisko, jednak z
częścią twierdzeń nie mogę się zgodzić

Filip Sielimowicz napisał(a):
> Wydaje mi się raczej, że nadużywa się tu terminu "utrata obiektowości",
> a dokładniej: zaczyna się postrzegać jako "nieobiektowe" wszystko to,
> co "niesamodzielne i nieuniwersalne".

Nie twierdzę, że "obiektowe" powinno być "uniwersalne". Często o sile
obiektu decyduje jego wąska specjalizacja.
Samodzielność jednak, przynajmniej w pewnym stopniu _jest_ dla mnie
wyznacznikiem "obiektowości". Bierze się to z mojego oczekiwania wobec
obiektu, któremu powierzam jakieś dane, że zrobi z nich dobry użytek,
stworzy jakąś wartość dodaną. Co mi z tego, że wrzucę do obiektu
referencje do kilku innych obiektów, gdy on nie zrobi z nimi nic
użytecznego? To potrafi każda struktura danych z języków proceduralnych.
Nawiązując do znanej przypowieści jest to tak, jak ze
"sługą złym i gnuśnym", któremu powierzono talent, a on go zakopał w
ziemi. Co zrobił właściciel talentu po powrocie? Zabrał ten talent temu
słudze i dał go innemu, który dobrze zarządził swoimi. Tak samo ja
zabieram takim obiektom te dane, które mają, by dać je tym, które zrobią
z nimi coś użytecznego :)
Jasne, w pewnych skrajnych sytuacjach samo to,
że obiekt trzyma pewne dane w jednym miejscu stanowi jakąś wartość, ale
często obiekt taki nadaje się do powierzenia mu jakiejś odpowiedzialności

> Natomiast nie można tracić z horyzontu podstawowej kwestii: obiektowość 
> ma służyć
> wierniejszemu odwzorowywaniu rzeczywistości, a nie sobie samej. 

Przedstawił Pan fałszywą alternatywę - obiektowość sama dla siebie
kontra obiektowość w służbie wierniejszego odwzorowania rzeczywistości.
Wyznaczanie obiektowości jakiegoś przeznaczenia, misji do spełnienia
wydaje mi się zupełnie nietrafionym pomysłem, podobnym do pomysłu 
podporządkowywania sztuki polityce w ZSRR w latach 50', określanego 
mianem socrealizmu.
Obiektowość jest pewnym narzędziem o interesujących właściwościach,
którego można użyć do różnych celów, a tak się składa przy okazji, że
całkiem nieźle potrafi ono też odwzorować rzeczywistość.
Trzeba mieć na uwadze, w jaki sposób podejście to się narodziło i
rozwinęło - a rozwinęło się poprzez naturalną ewolucję technik
strukturalnych (które lubię nazywać określeniem pana Wrighta "algorytmy
+ struktury danych"). W pewnym momencie ktoś zauważył, że grupowanie
danych wraz z procedurami operującymi na nich to dobry pomysł, co
zaprowadziło do powstania koncepcji modułów, a później obiektów. Dla
mnie więc na przykład obiektowość stanowi pożyteczną cechę języka
programowania, umożliwiającą w dobry sposób organizować programy.
Doceniam możliwości podejścia obiektowego w zakresie możliwości
modelowania świata rzeczywistego, jednak też nie przeceniałbym tej
właściwości. Język obiektów to jednak nie do końca język klienta i może
dlatego właśnie mamy do czynienia z rozwojem alternatywnych podejść do
programowania, jak z językami domenowymi na przykład. Co do czego nie
mam wątpliwości, to do użyteczności technik obiektowych w praktyce
programistycznej.

> Wydaje 
> mi się, że
> bardzo często miesza się różne poziomy analizy, projektu i 
> implementacji. 

Z moich doświadczeń z kolei wynika, że fazy analizy, projektu i 
implementacji zbyt często nie są ze sobą należycie zintegrowane, a nade 
wszystko pętle zwrotne nie funkcjonują na tyle dobrze, żeby na czas 
przekazywać między sobą zaktualizowaną wiedzę o rzeczywistości.

> Mam wrażenie
> że niektórzy wydają z siebie wielkie westchnienia zdumienia, kiedy 
> okazuje się, że
> obiektowość zaangażowana na poziomie implementacyjnym, technicznym ma 
> zupełnie inną
> twarz niż obiektowość działająca niby w tym samym obszarze biznesowym, 
> ale na poziomie
> analizy i projektu.

Westchnienie zdumienia, czy nawet zawodu można wydawać próbując
bezkrytycznie podążać za wzorcami wyznaczonymi przez jakieś autorytety,
jak konsorcja firm informatycznych, a nie mając wyrobione własne
spojrzenie, z dozą zdrowego krytycyzmu.
Formułując treść posta rozpoczynającego ten wątek celowo zamierzałem
sprowokować do dyskusji obrońców dogmatów J2EE.

Jednak w miarę trwania dyskusji uświadamiam sobie coraz mocniej, że J2EE
to osobny (i nawet stosunkowo dobrze funkcjonujący) świat, rządzący
się swoimi prawami, które z obiektowością mają czasem więcej, a czasem
mniej wspólnego (z pewnością więcej, niż niektóre rozwiązania 
proponowane przez wiodącą technologię konkurencyjną i to należy 
docenić), jednak tworzą razem kompletną i w miarę harmonijną całość.

Zdaję sobie sprawę, że obiekty w rodzaju TO nie są wyłącznie specyfiką
J2EE, tylko raczej wszelkich platform rozproszonych, ale ciekawi mnie,
czy stosuje się niekiedy w nich podejście polegające na umieszczeniu w
nich większej dozy logiki, niekoniecznie nawet wchodząc na grunt
technologii mobilnych agentów.

> Wiele wzorców projektowych wręcz jawnie rozpina dane od funkcji i 
> widzimy to zarówno
> w idei takiej jak MVC, jak też we wspomnianym TransferObject i 
> występujących w kontekście
> DAO i BusinessObject. 

Tylko MVC z powyższych wzorców jest wspomniany w "Design Patterns" GoF. 
Wzorce projektowe J2EE są jednak odrobinę czymś innym, niż wzorce GoF.

> Niektórzy krzyczą, że to jakieś łamanie zasad 
> obiektowości.

Bo to jest - a przynajmniej jest to obiektowości mocna redukcja

> A ja mówię: zależy gdzie. Jeśli ktoś obiektowość rozumie jako: "obiekt 
> musi odwzorowywać
> całą wiedzę zgromadzoną we wszechświecie o tym, do czego jest przydatny" 
> to ja mówię "bzdura totalna".

Wie Pan, że nawet zgodzę się z Panem :) Tylko, że dlaczego całą, a nie 
tylko tą przydatną w kontekście systemu, w którym pracuje? Poza tym nikt 
nie twierdzi, że obiekt powinien odwzorowywać nawet całą wiedzę 
przydatną w danym kontekście, a jedynie tę jej część, która z różnych 
względów jest mu bardziej przynależna, niż innym obiektom tego systemu.

> To nie ma po prostu żadnego przełożenia na rzeczywistość.
> 
> Mamy nóż i mamy chleb. 
[...]

To dosyć oryginalne obiekty w systemie informatycznym :)
Doceniając obrazowość przykładów wyrażam powątpiewanie w możliwości
zastosowania analogii do prawdziwych systemów z konkretnie postawionymi
wymaganiami.
A wniosek o człowieku, który wie, czego użyć i w jakim celu narzuca
skojarzenie ze starymi, dobrymi algorytmami i strukturami danych.
Tylko że niedomagającymi co jakiś czas z powodu różnych niekorzystnych
zjawisk, np. z braku ukrywania danych.

> Bo chyba nikt mi 
> nie powie, że
> paleta powinna mieć metodę "użyj Kajtka do tego żeby się przenieść na 
> Marszałkowską".

Paleta nie... ale wirus grypy?

> Uważam, że należy dbać o to, by nie pakować kosmicznych problemów na 
> barki prostych narzędzi
> cukiernika, bo przerażenie i dezorientacja tychże bezpośrednio przekłada 
> się na to, że się
> potem stos palet najzwyczajniej nie trzyma kupy i Kajtek na 
> Marszałkowskiej otwierając drzwi
> od samochodu wysypuje chleb klienta prosto na ulicę.

Zgadzając się zupełnie co do wniosków dotyczących branży cukierniczej,
wyrażam powątpiewanie w ich słuszność w branży informatycznej :)

Przemek