🚀 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.
Upraszczajac 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 w praktyce 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.

Ufff ...
Trochę ta sytuacja się zmienia, jeśli zamiast 'jednego dużego systemu'
mamy wiele małych systemików silnie powiązanych interfejsami niskiego 
poziomu,
czyli przez kopiowanie danych z bazy do bazy (procesy ETL). Ale zostawię
już tak, jak jest ;)))