🚀 go-pugleaf

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości 
news:dnn919$ebu$1@news.onet.pl...
...

Generalnie w zasadzie nie ma się co za dużo spierać. Wiele kwestii, które 
Pan
naświetlił trudno podważyć. Pozwolę sobie więc bardzo wybiórczo potraktować 
Pana
wypowiedź i przedstawić kilka własnych uwag mniej lub bardziej z nią 
zwiazanych,
ale trzymających się wątku.

> 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.

:) Ten fragment oczywiscie najbardziej przykuł moją uwagę ... Zastanawia 
mnie
dlaczego obiektowość porównał Pan do sztuki ;). Owszem - zapewne wielu
projektantów orzących na co dzień nudne problemy biznesowe klienta
bardzo chętnie widzi siebie jako osoby o umysłach nieskrępowanych żadnymi
konwenansami i pełnych twórczego zapału osobowościach ekscentrycznych
artystów ;). Natomiast ja bym w tym miejscu zaakcentował, że obiektowość
jednak jest podporządkowywana - pieniądzom ;). Ale o tym zapewne dalej.

> 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.

O, tu przerwę.
Po pierwsze: nie podważam sensowności takiego działania (grupowania danych
z operacjami na nich). Ale to przecież nie jest żadna kompletna idea,
szczególnie w obliczu dużych systemów informatycznych. W szczególności:
takie grupowanie także podlega licznym ograniczeniom. Ale o tym zapewne 
dalej.
Po drugie: ważne jest, że wskazał Pan pewien pośredni cel "organizować
programy". Jest to bardzo dobry punkt wyjścia do tego, by rozważać
po co i jak stosować obiektowość - i uczyniłbym z tej idei termin-klucz,
by łatwiej zachować skupienie w dyskusji.

> 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.
> ...
> 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.

Kolejne terminy-klucze: "odwzorowanie rzeczywistosci klienta" i
"koszt wprowadzania zmian/rozwijania systemu".

> 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.

W mojej ocenie robi się to - ale jak już wspomniałem - w sposób ograniczony.
Twierdzę, że tym bardziej ograniczony, im z większym systemem mamy do 
czynienia.

> 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.

Kolejny termin klucz: "przynależność wiedzy do elementów systemu"

>> To nie ma po prostu żadnego przełożenia na rzeczywistość.
>>
>> Mamy nóż i mamy chleb.
> [...]
>
> To dosyć oryginalne obiekty w systemie informatycznym :)

No to weźmy program źródłowy i skaner(analizator syntaktyczny).
Analogia jest bardzo bliska - drugi "umie" ciąć ten pierwszy - i
robi to wg. bardzo prostych, w dużym stopniu niezależnych od cietej
materii zasad: wyłapuje liczby, identyfikatory a tnie np. po białych 
znakach.

Do kompilatora zintegrowanego ze środowiskiem uruchomieniowym jednak
jeszcze baaardzo daleko. Zupełnie ktoś inny decyduje o tym , co dokładnie
kroić (podstawia chleb pod nóż) i kiedy. A także odpowiada na pytania
"po co", "co dalej".

> Doceniając obrazowość przykładów wyrażam powątpiewanie w możliwości
> zastosowania analogii do prawdziwych systemów z konkretnie postawionymi
> wymaganiami.

No cóż ;). Ja w każdym bądź razie mówiąc o tym, mam bardzo konkretny
system na myśli ;)

> 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.

To jest problem ogólniejszy. IMHO samo pojęcie obiektu wcale tego problemu
dobrze nie rozwiązuje. Zaś źle rozumiane pojęcie obiektowości jeszcze 
bardziej
problem komplikuje (ukrywanie danych i funkcji). Natomiast stosowanie
niektórych wzorców projektowych, separujacych jedne dane od innych, 
ukrywających
klasy za interfejsami itp właśnie na ten problem stara się odpowiedzieć.
Ale o tym zapewne dalej.

> Paleta nie... ale wirus grypy?

Wirus grypy powinien się umiejętnie wmontować w gotową ciepłą komórkę, jeśli
taką wykryje przy swojej ściance. To wszystko ;). Reszta dzieje się sama.
Chyba, że majac na myśli "wirus grypy" klient ma na myśli "epidemię
grypy" i interesują go statystyczne dane o centrach tej epidemii i
charakterystyka jej rozprzestrzenia się na jakiejś mapie. A więc zależy
od wymagan klienta.

> 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 :)

Niestety idziemy teraz ławą szerszą, niż Hitler rozpoczynając II wojnę
światową. Ciężko o wszystkim, co powyżej, rozmawiać w jednym skromnym wątku.
Jednak spróbuję, choć przytłoczony znikomością własnych zasobów czasowych
pożeranych w soboty przez rodzinę (i bardzo dobrze ...).

Widzę dwa duże tematy-procesy przy okazji omawiania których można by się
odnieść do wyżej wymienionych kluczy:

1. Modelowanie rzeczywistości klienta.
2. Organizacja procesów wytwórczych.

Z każdym z tych tematów wiąże się ściśle pojęcie kosztu. Oba te procesy 
poprzez
koszty wchodzą ze sobą w konflikt przy wytwarzaniu każdego systemu 
informatycznego.
Upraszczając: pierwszy proces jest najbliższy interesom klienta, bo 
interesem klienta
jest, by system był jak najdokładniejszy. Czyli klient chciałby, by 
zaangażować
w produkcję jak najwięcej wiedzy i pracy.
Drugi zaś proces jest najbardziej po stronie producenta - jak najmniej się 
nadowiadywać
i napracować aby uzyskać założony efekt - bo i wiedza i praca kosztują.

Podkreślę jednak: "konflikt". Oznacza to, że wszystko to, co wcześniej 
mówiliśmy
będzie oceniane dwojako: jako fajne albo jako niefajne - zależnie od tego, 
kto na to
spojrzy. Każde słowo-klucz, które wcześniej wymieniłem daje "zysk" i 
"koszt",
przy czym jest kilka ogólnych zależności: im mniejszy system, tym bardziej 
dominuje
punkt 1 i skupienie na kliencie. Im większy system, tym bardziej wchodzimy
w sferę nakreśloną przez punkt 2, czyli problemy własne producenta. 
Przypadki skrajne:

A. Malutki systemik. Analityk/projektant/programista we własnej osobie 
prowadzi
działalność gospodarczą, idzie na krótką rozmowę do klienta i następnego
dnia daje mu malutki programik, który spełnia potrzeby tego ostatniego. I 
obaj
zapominają o sprawie. Programista robi "jak mu się podoba", a więc dominuje
jego własne poczucie wygody. Nie istnieją żadne standardy poza tymi, które 
sam sobie
narzuci. W takim wypadku dużo wygodniej i prościej będzie nie dzielić włosa
na czworo i się nie rozdrabniać. Obiektowość świetnie się tu nada jako 
czynnik
organizacyjny pozwalajacy utrzymać wszystko w minimalnej ilości kawałków i 
będzie
to działać na najbardziej ogólnym poziomie systemu. Problem "widzialności" 
danych
tu w ogóle nie istnieje. Bardzo ograniczona jest też problematyka separacji
problemów biznesowych od problemów technicznych. Nie istnieją problemy 
standaryzacji
i pochodne od nich probelmy wprowadzania zmian i rozwoju systemu. Można olać 
wszelkie
idee typu MVC czy Business-Object. Robimy formatkę, na niej klawisz, a ten 
klawisz robi
nam wszystko, czego potrzebujemy. Tak to widzi klient i tak to jest 
zaprogramowane -
w jednej klasie.

B. Duży system. Duży - bo ma dużą funkcjonalność i gromadzi duże dane 
(ilościowo
i pod wzgledem różnorodności) oraz pracuje nad nim duża liczba osób - 
powiedzmy co
najmniej kilkadziesiat, dajmy na to 50. Jest też obliczony na rozwój i 
modyfikacje.
Powiedzmy, że system ma powyżej 5000 tzw. punktów funkcyjnych.
W takim systemie, poza tym, że ma on spełnić wymagania klienta, istnieje 
wiele wymagań,
które klienta właściwie nie obchodzą - bo nawet ich nie rozumie (ale za 
które musi
zapłacić ...)-  są to właśnie te kwestie: wysoka standaryzacja wewnętrznych 
rozwiązań,
rozwiązane problemy precyzyjnego przypisania wiedzy biznesowej do elementów 
systemu.

Spójrzmy na typowy, duży system: duża, możliwie scentralizowana, baza danych
(różne już ćwiczono koncepcje, jednak centralizacja danych pomimo prób 
podważenia
jej konieczności - ciągle okazuje się stosunkowo najmniej problematyczna - 
co widać
dobrze w systemach bankowych). Tradycyjnie - jest to baza relacyjna.
Teraz trochę powędrujmy po tym systemie szlakami z punktu 1, czyli od strony
wymagań klienta.
Potraktujmy w tym systemie dane(struktury danych) jako niski poziom modelu,
a raporty jako wysoki(najbliższy klientowi). W każdym rzeczywistym systemie
informatycznym od razu zauważymy, że nie istnieje coś takiego, jak 
jednoznaczne
przypisanie raportu do tabeli danych. Owszem - będzie bardzo duża klasa 
raportów,
które będą ściśle związane z danymi - np. raporty potwierdzajace operacje
wprowadzenia/modyfikacji danych. Ale poza tym będzie istnieć ogromna
różnorodność raportów, które korzystają z danych w sposób niemal dowolny,
w tym 50% procent będzie się np. odwoływać do danych osobowych klientów 
instytucji,
dla której tworzymy system. Będą to np. raporty ukazujące klientów w 
kontekście
innych danych systemu: jak wygląda klient w towarzystwie swoich kont 
bankowych,
jak wyglada klient w towarzystwie produktów, które kupuje, jak wyglada 
klient
w towarzystwie rachunków, które płaci terminowo, jak wyglada klient w 
towarzystwie
innych klientów mieszkajacych w tym samym rejonie albo mających ten sam 
zawód, jak
wygląda klient w towarzystwie promocji, z których skorzystał, jak wyglada 
klient
w towarzystwie swojej żony, jeśli jest ona także w systemie, jak wygląda 
klient
z punktu widzenia przychodów instytucji.

POWSTAJE WIEC PIERWSZE PYTANIE: Czy to oznacza, że obiekt "klient" ma mieć w 
sobie
metody do wywoływania 50% raportów systemu ?

Odpowiedź jest oczywista: NIE. Wiec może inaczej: może część raportów 
powinna być
bezpośrednio w kliencie, a część "gdzieś indziej" ? I znów pada odpowiedź: 
NIE.
Raporty należy po prostu organizować oddzielnie od danych. Każda duża baza 
danych
będzie się charakteryzować tym, że niektóre dane będą używane wielokroć 
bardziej
intensywanie (właśnie dane klientów i produktów oferowanych klientom), niż 
inne.
Dlatego to nie dane narzucają sposób organizacji systemu. Jednostki 
organizacyjne
są dużo bliższe klientowi i jego własnej strukturze organizacyjnej. Ta 
narzuca
moduły-podsystemy, a te są najbardziej ogólnym i naturalnym poziomem 
organizacji
funkcjonalności systemu.
Na przykładzie raportów widać to wyraźnie, ale ta własność wchodzi w system
znacznie głębiej. Raporty i formatki systemu są najbliższe klientowi i 
najlepiej
poddają się podziałowi na moduły. Nie ma między nimi żadnych zależności.
Niżej jednak są funkcje logiki które doprowadzaja dane do raportów i za 
pośrednictwem
których dane te są także modyfikowane. I funkcje inne - np. odpowiedzialne 
za komunikację
z innymi systemami. Znów powstaje problem gdzie je umieścić - może w 
raportach, a może
w danych ? A co z resztą ? Znów: jest cała klasa funkcji zapisujacych i 
odczytujących
dane, które można by łatwo związać z konkretnymi tabelami w bazie danych. 
Jeśli
mamy do czynienia z systemem z dominującą sferą raportowo-ewidencyjną,
to można się ewentualnie pokusić o takie rozwiązanie - część tu, część tam.
Ale w systemie bankowym, gdzie poza ewidencją istnieje cała złożona logika 
biznesowa
dotycząca samej li tylko obsługi rachunków (i ogromna jej część w ogóle nie 
jest używana
w formatkach, czy raportach) ? Czy to oznacza, że obiekt "rachunek ROR"
ma mieć 1000 metod związanych ze swoją obsługą - od strony bankowej (wpłaty, 
wypłaty,
naliczanie odsetek, opłat, prowizji), od strony księgowej, od strony 
marketingowej,
od komunikacji z systemami kart płatniczych, od komunikacji z GIIF'em, od 
komunikacji
z KIR'em ... ? Znów odpowiedź jest oczywista: NIE. Funkcje te wymagają 
własnej,
złożonej organizacji, oddzielonej od organizacji danych, na których operują.
Siłą rzeczy powstaje więc bardzo mocno zarysowana warstwa funkcji logiki, 
gdzie
w zasadzie wszystkie bezpośrednio wiążą się z jedną-klikoma tabelami - 
rachunkiem
i całą masą tabel uzupełniajacych.

Ufff ...

Teraz pójdźmy szlakami punktu 2, czyli poorganizujmy proces wytwórczy.
Chciałbym krótko, wiec proszę: mamy ten nieszczęsny ROR. I mamy 
programistów: jedna
osoba specjalizuje się w robieniu raportów, inna osoba modeluje dane, trzy 
inne tworzą
funkcje logiki: jedna wpłaty i wypłaty z prowizjami, przyjmowanie, 
wyprowadzanie przelewów
itp, druga zmienia na rachunku datę (czyli nalicza odsetki), trzecia bawi 
się w wykrycie,
że trzeba powiadomić klienta, iż przekroczył saldo debetowe. Jeśliby te trzy 
osoby miały
jednocześnie produkować kod w jednej klasie danych (rachunek bieżący) to ja 
nawet nie chcę
myśleć co by z tego wyszło. Jak w ogóle im ułatwić pracę - a dobrze jest to 
robić narzucając
interfejsy - o czym poniżej.
Jest bowiem kolejna osoba - ta która zajmuje się np. kwestią zapewnienia 
transakcyjności
w systemie. Ta osoba ma sprawić, by wszystkie funkcje, które tworzą 
pozostałe osoby
były uruchamiane w sposób jednolity w ściśle zakreślonych transakcjach. Jest 
jedno wyjście:
trzeba narzucić wszystkim innym programistom standardy, wg. jakich mają 
pisać funkcje logiki.
Można to zrobić tak: "twoim obowiązkiem jest dziedziczenie każdej funkcji 
biznesowej
po klasie abstrakcyjnej 'funkcja biznesowa', a w niej masz do dyspozycji 
funkcje otwórzTransakcję
i zamknijTransakcję - z których masz korzystać. Można też inaczej, ale 
podobnie: " ... a w niej
masz metodę run(Transakcja t), którą masz pokryć i w tej metodzie masz już 
transakcję gotową".
I to jest właśnie idea BusinessObject - odseparowanie systemu zarządzania 
transakcjami
od samej logiki biznesowej, która z nich korzysta. Więcej: to dokładne 
ukrycie mechanizmów
transakcji przed programistą: do programisty należy utworzenie komponentu, 
który ma implementować
jakieś metody, narzucone np. przez interfejs (żadnych klas abstrakcyjnych 
chowajacych w swoich
trzewiach cały system transakcji) i musi też ew. wiedzieć jak taką funkcję 
uruchomić - za
pośrednictwem zewnętrznego procesora funkcji biznesowych. A ów procesor to 
już zupełnie inny
element systemu i dla innego programisty (jeśli nie jest dostarczony z 
zewnątrz), nie majacy
nic wspólnego z ddziedziną biznesową.

Problem jest ogólniejszy: jak zapewnić taką organizację pracy wielu osób, by 
nie wchodziły sobie
one w paradę a jednocześnie potrafiły nawzajem korzystać ze swojej pracy i 
by ich praca(kod)
był zrozumiały dla innych (wprowadzanie zmian przez inne osoby). To problemy 
odpowiedzialności,
użyteczności i przejrzystości. Dzielenie pracy, którą trzeba wykonać na małe 
elementy jest
konieczne do tego, by ten efekt uzyskać. A wsparciem takiego podziału jest 
dzielenie różnych
elementów systemu na małe komponenty, implementowane oddzielnie.
To oczywiscie kosztuje ;). Ale bez tego trudno efektywnie zbudować i 
utrzymać złożony system
informatyczny - gdzie np. nowy, młody programista (tani programista ...) w 
zasadzie pierwszy
raz praktycznie styka się z pojęciem transakcji, a co to jest ROR to wie 
tylko tyle, ile mu
w banku w umowie napisali jak sobie zakładał konto.

Uf ...
Koniec.