🚀 go-pugleaf

Robert Perlinski napisa³(a):
> J2EE to przede wszystkim (choc nie tylko) "distributed components", ktore z
> zalozenia nie sa (i nie powinny byc) "klasycznymi" obiektami. Transfer
> Objects w takich wypadkach to jedyne sensowne rozwiazanie.

A jakie "bezsensowne" alternatywy masz na my¶li?

Przemek

Przemek Pokrywka napisa³(a):
> Robert Perlinski napisa³(a):
>
>> J2EE to przede wszystkim (choc nie tylko) "distributed components",
>> ktore z zalozenia nie sa (i nie powinny byc) "klasycznymi" obiektami.
>> Transfer Objects w takich wypadkach to jedyne sensowne rozwiazanie.
>
>
> A jakie "bezsensowne" alternatywy masz na my¶li?

Nie bêdê ocenia³ sensowno¶ci alternatyw, ale pozbycie siê TO skutkuje
tym, ¿e po przes³aniu obiektu do innej warstwy mamy:
1. Albo obiekt, którego wszystkie wywo³ania metod s± zdalne (tzn.
odwo³uj± siê do warstwy, w której zosta³ utworzony).
2. Albo obiekt, który jest kopi± orygina³u i jest od³±czony od warstwy,
z której pochodzi.

Pozdrawiam

--
Grzegorz Gruza
Odpowiadaj±c usuñ "spamerom_nie." z adresu!!!

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

> Czy transfer objects (jako pattern J2EE) sa obiektowe?
> Bo mi sie wydaje, ¿e nie

J2EE to przede wszystkim (choc nie tylko) "distributed components", ktore z
zalozenia nie sa (i nie powinny byc) "klasycznymi" obiektami. Transfer
Objects w takich wypadkach to jedyne sensowne rozwiazanie.

Robert Perlinski

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

>> J2EE to przede wszystkim (choc nie tylko) "distributed components",
>> ktore z zalozenia nie sa (i nie powinny byc) "klasycznymi" obiektami.
>> Transfer  Objects w takich wypadkach to jedyne sensowne
>> rozwiazanie.

> A jakie "bezsensowne" alternatywy masz na mysli?

Zlozmy, ze mamy klase Employee z nastepujacymi atrybutami: id, imie,
nazwisko, wiek. "Klasyczny obiekt" bedzie wygladal mniej wiecej tak
(oczywiscie definicja bardzo uproszczona):

public iterface Employee
{
  String getID();
  String getFirstName();
  String getLastName();
  int getAge();
  // pomijam "settery"

  void save();
  void load(String id);
}

W przypadku jednak, kiedy mamy do czynienia z "distributed objects" powyzsza
definicja ma w wiekszosci wypadkow maly sens praktyczny i zwykle bedzie
wygladac nastepujaco:

public iterface EmployeeService
{
  void save(EmployeeTO employee);
  EmployeeTO load(String id);
}

gdzie EmployeeTO jest odpowiednikiem Transfer Object i sluzy jedynie do
przesylania danych.

Robert Perlinski

Dziêkujê obydwu Panom za wyja¶nienia, jednak nie bardzo o to mi
chodzi³o. Pisz±c, ¿e wydaje mi siê, ¿e transfer objects nie s±
obiektowe, mia³em na my¶li to, ¿e s± one typowymi pojemnikami na dane,
których logika jest ograniczona wy³±cznie do kontroli dostêpu do
okre¶lonych atrybutów (przynajmniej opieraj±c siê na informacjach z:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)

Takie obiekty s± dla mnie ma³o interesuj±ce, bo nie ró¿ni± siê zbytnio
od typowych struktur danych wystêpuj±cych w programowaniu strukturalnym.
Co by mog³o byæ ciekawe (a mo¿liwe do zrealizowania w technologii
obiektowej), to zachowanie, migruj±ce wraz z obiektem na inny wêze³
sieci i oddzia³uj±ce z nowym kontekstem.
Tego jednak nie da siê u¶wiadczyæ w J2EE.

Przemek

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

> Dziêkujê obydwu Panom za wyja¶nienia, jednak nie bardzo o to mi chodzi³o.
> Pisz±c, ¿e wydaje mi siê, ¿e transfer objects nie s±  obiektowe, mia³em na
> my¶li to, ¿e s± one typowymi pojemnikami na dane,

Dokladnie tak jest. Nie sadze jednak, aby problemy, ktore TO rozwiazuje
(przynajmniej w kontekscie Distributed Components), dalo sie rozwiazac
inaczej.

> Co by mog³o byæ ciekawe (a mo¿liwe do zrealizowania w technologii
> obiektowej), to zachowanie, migruj±ce wraz z obiektem na inny wêze³ sieci
> i oddzia³uj±ce z nowym kontekstem. Tego jednak nie da siê u¶wiadczyæ w
> J2EE.

Jest to jak najbardziej wykonalne, w koncu klasa w Javie to tylko zlepek
bitow, ktore bez problemow mozna przeslac po sieci. Nie o to jednak chodzi.
W (wiekszosci) przypadkow bowiem kontekts takiego obiektu nie jest mozliwy
do przeslania, a nawet gdyby bylo to mozliwe, zwykle nie jest pozadane.
Rzecz w tym bowiem, aby w konwersacji "klient-serwer" kazda ze stron
pozostala w swoim srodowisku kontekstowym. W przeciwnym wypadku sens takiej
architektury zaczyna byc problematyczny.

Pomiedzy klientem i serwerem, przesyla sie wiec tylko dane. A do tego
wlasnie sluza Trasfer Objects.

Oczywiscie powyzsze bazuje na uogolnieniach. Ale "J2EE patterns" generalnie
wlasnie takich uogolnien dotycza.

Robert Perlinski

Dnia 07.12.2005 Przemek Pokrywka <adres@zastrzezony.com> napisa³/a:
> Czy transfer objects (jako pattern J2EE) s± obiektowe?
> Bo mi siê wydaje, ¿e nie
>

W przypadku transfer object, wzorzec ten wprowadzony zosta³ w celu
optymalizacji zdalnych wywo³añ metod, a jak wiadomo - ka¿da optymalizacja ma
zwykle jakie¶ efekty uboczne, którymi zwykle jest koszt zwi±zany ze
zmniejszon± czytelno¶ci± kodu albo uzale¿nieniem od platformy sprzêtowej (akurat
w tym przypadku ten drugi aspekt odpada :-)). Utrata obiektowo¶ci jest w
tym przypadku cen± za wydajno¶æ.

--
Micha³

U¿ytkownik "Micha³ S³ocinski" <nobody@nowhere.com> napisa³ w wiadomo¶ci
news:slrndpo7kg.a7o.nobody@localhost.localdomain...
> Dnia 07.12.2005 Przemek Pokrywka <adres@zastrzezony.com> napisa³/a:
>> Czy transfer objects (jako pattern J2EE) s± obiektowe?
>> Bo mi siê wydaje, ¿e nie
>>
>
> W przypadku transfer object, wzorzec ten wprowadzony zosta³ w celu
> optymalizacji zdalnych wywo³añ metod, a jak wiadomo - ka¿da optymalizacja
> ma
> zwykle jakie¶ efekty uboczne, którymi zwykle jest koszt zwi±zany ze
> zmniejszon± czytelno¶ci± kodu albo uzale¿nieniem od platformy sprzêtowej
> (akurat
> w tym przypadku ten drugi aspekt odpada :-)). Utrata obiektowo¶ci jest w
> tym przypadku cen± za wydajno¶æ.

Ja bym nie powiedzia³, ¿e to kwestia wydajno¶ci ...
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".
Natomiast nie mo¿na traciæ z horyzontu podstawowej kwestii: obiektowo¶æ ma
s³u¿yæ
wierniejszemu odwzorowywaniu rzeczywisto¶ci, a nie sobie samej. Wydaje mi
siê, ¿e
bardzo czêsto miesza siê ró¿ne poziomy analizy, projektu i implementacji.
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. A tymczasem ja siê dziwiê, ¿e inni siê tak dziwi± ;).

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. Niektórzy krzycz±, ¿e to jakie¶ ³amanie zasad
obiektowo¶ci.
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". To nie ma po prostu ¿adnego prze³o¿enia na rzeczywisto¶æ.

Mamy nó¿ i mamy chleb. Pytanie: czy to nó¿ powinien wiedzieæ, jak ma kroiæ
chleb, czy
chleb ma wiedzieæ, jak daæ siê pokroiæ no¿owi ? Ani jedno ani drugie. To
cz³owiek
wie, jak u¿yæ no¿a, by pokroiæ chleb. I jak zje¶æ chleb. Albo jak rzucaæ
no¿em. Albo jak
chleb pokruszyæ i rzuciæ ptactwu. Ptactwo samo sobie chleba nie drobi (mimo,
¿e drobiem
jest, jak mówi±). Chleb siê te¿ sam raczej dla ptactwa nie drobi, choæ mo¿na
by tu siespieraæ,
czy rzeczywi¶cie siêsam z czasem nie pokruszy ...

Jak mistrz cukierni wo³a: "Kajtek, bierz no te paletê z chlebem i pêd¼ na
Marsza³kowsk±
do sklepu, bo dzi¶ otwieraj± wcze¶niej", to sprawa jest oczywista: to Kajtek
ma wiedzieæ,
jak wzi±æ ten TransferObject i gdzie z nim polecieæ. Bo chyba nikt mi nie
powie, ¿e
paleta powinna mieæ metodê "u¿yj Kajtka do tego ¿eby siê przenie¶æ na
Marsza³kowsk±".

Wcale to nie znaczy jednak, ¿e paleta z chlebami to jest jaka¶
prehistoryczna struktura
a nie obiekt, wiêc jest fe. Wcale nie: paleta jest obiektem, tyle, ¿e kto¶
zauwa¿y³, ¿e
jego kompetencje w kwestii wp³ywu na rzeczywisto¶æ s± bardzo ograniczone,
wiêc nie snu³
fantazji na temat: "a gdyby tak moja paleta potrafi³a sama podpi±æ siê do
NASA, z³amaæ
szyfry, zamienic siê miejscem z g³ównym astronaut± to mogliby¶my ju¿ dzi¶
stosunkowo tanio
dostarczyæ ¶wie¿y chleb na Marsa". Zamiast fantazji mamy konkret w postaci
metody:
"zatrza¶nij", któr± Kajtek u¿ywa, kiedy uk³ada wiele palet w stos i chce, by
ta co na
górze prost± zapadk± przymocowa³a siê do tej, co pod ni±. To jest w³a¶nie
to, czego
oczekuje Kajtek od palety w kwestii obiektowo¶ci i to, w czym paleta mo¿e
byæ i jak
najbardziej jest kompetentna. Powiem nawet wiêcej: paleta czuje ogromn±
przyjemno¶æ,
kiedy mo¿e tego typu zadanie wykonaæ sprawnie i profesjonalnie, natomiast
czuje ogromne
przera¿enie, kiedy kto¶ zaczyna do niej zamiast chleba wk³adaæ system
nawigacji satelitarnej
i puszczaj±c oko szepcze: no moja ma³a, ju¿ nied³ugo bêdziesz ...

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

A pogoda dzi¶ nie najlepsza.

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

[...]

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

To jest true, pod warunkiem, ¿e pod pojêciem 'wszech¶wiat' rozumiemy
wszystko, co w obiekcie jest wa¿ne z punktu widzenia tworzonego
systemu informatycznego.  Przyk³adowo, dla programu 'hello, world'
wrzech¶wiatem bêdzie standard output ;)

--
http://www.piotr.dembiñski.prv.pl

U¿ytkownik ""Piotr Dembiñski"" <pdemb@gazeta.pl> napisa³ w wiadomo¶ci
news:87y82raafe.fsf@hector.domek...
> "Filip Sielimowicz" <sielim@poczta.onet.pl> writes:
>
> [...]
>
>> 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".
>
> To jest true, pod warunkiem, ¿e pod pojêciem 'wszech¶wiat' rozumiemy
> wszystko, co w obiekcie jest wa¿ne z punktu widzenia tworzonego
> systemu informatycznego.  Przyk³adowo, dla programu 'hello, world'
> wrzech¶wiatem bêdzie standard output ;)

No chwileczkê ... Chyba jednak nie mówimy o tym samym ;). Co jest
wszech¶wiatem
dla palety z chlebem ? Czy sklep na Marsza³kowskiej nie nale¿y do tego
wszech¶wiata ? A czy paleta musi/powinna cokolwiek o nim "wiedzieæ" ?
Paleta ma mieæ uchwyt i pojemno¶æ, ewentualnie miejsce na etykietkê - gdzie
j± dostarczyæ. Wtedy znajdzie siê mnóstwo "wszech¶wiatów", które j± chêtnie
przyjm±. Niektóre jako opa³ na ten przyk³ad. Czy paleta musi wiedzieæ o tym,
¿e kto¶ j± kiedy¶ ustawi jako mebel w mieszkaniu ?

A spogladaj±c ogólniej: czy obiekt ma gromadziæ tak¿e wszelk± _potencjaln±_
wiedzê
na temat tego, kto siê kiedy¶ urodzi w laboratorium i jaki mu pomys³ u¿ycia
wpadnie
do g³owy ?
Bo co innego uzupe³niæ obiekt typu paleta o dodatkowy atrybut typu "zrobiona
z ³atwopalnego tworzywa sztucznego", a co innego zaimplementowaæ w niej
metodê
"spal mnie" i wchodziæ w szczegó³y technologii procesu spalania. A mo¿e
Kajtek powinien ze sob± nosiæ instrukcjê obs³ugi w stylu: nie dotykaæ
tej wielkiej skrzyni przyczepionej do palety. To jest piec. Nie dotykaæ
tej bani przyklejonej pod skrzyni± - to jest butla ze sprê¿onymi pomys³ami
na rok 2008.

A czym jest analiza ? Analiza to wyznaczanie granic. Zaznaczanie ich czêsto
silniej, ni¿ w rzeczywisto¶ci.
Nastêpuj±ca po niej synteza nie polega na zamazywaniu tych granic, ale
na sk³adaniu w ca³o¶æ ograniczonych ale wyrazistych elementów.

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

> U¿ytkownik ""Piotr Dembiñski"" <pdemb@gazeta.pl> napisa³ w wiadomo¶ci
> news:87y82raafe.fsf@hector.domek...
>> "Filip Sielimowicz" <sielim@poczta.onet.pl> writes:
>>
>> [...]
>>
>>> 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".
>>
>> To jest true, pod warunkiem, ¿e pod pojêciem 'wszech¶wiat'
>> rozumiemy wszystko, co w obiekcie jest wa¿ne z punktu widzenia
>> tworzonego systemu informatycznego.  Przyk³adowo, dla programu
>> 'hello, world' wrzech¶wiatem bêdzie standard output ;)
>
> No chwileczkê ... Chyba jednak nie mówimy o tym samym ;). Co jest
> wszech¶wiatem dla palety z chlebem ? Czy sklep na Marsza³kowskiej
> nie nale¿y do tego wszech¶wiata ? A czy paleta musi/powinna
> cokolwiek o nim "wiedzieæ" ?

Heh, mo¿na to wys³aæ na pl.sci.filozofia :>

> Paleta ma mieæ uchwyt i pojemno¶æ, ewentualnie miejsce na etykietkê
> - gdzie j± dostarczyæ. Wtedy znajdzie siê mnóstwo "wszech¶wiatów",
> które j± chêtnie przyjm±. Niektóre jako opa³ na ten przyk³ad. Czy
> paleta musi wiedzieæ o tym, ¿e kto¶ j± kiedy¶ ustawi jako mebel
> w mieszkaniu ?

Paleta w aspekcie umeblowanie powinna wiedzieæ ;)

> A spogladaj±c ogólniej: czy obiekt ma gromadziæ tak¿e wszelk±
> _potencjaln±_ wiedzê na temat tego, kto siê kiedy¶ urodzi
> w laboratorium i jaki mu pomys³ u¿ycia wpadnie do g³owy ?

Oczywi¶cie nie.  Chyba ka¿dy modelarz wie, ¿e zawsze przyjmuje siê
punkt widzenia tworzonego systemu.  Jak system siê rozszerza, to
i punkt widzenia mo¿e siê przesun±æ.

> Bo co innego uzupe³niæ obiekt typu paleta o dodatkowy atrybut typu
> "zrobiona z ³atwopalnego tworzywa sztucznego", a co innego
> zaimplementowaæ w niej metodê "spal mnie" i wchodziæ w szczegó³y
> technologii procesu spalania.

To chyba zahacza o MUDy, e?

> A mo¿e Kajtek powinien ze sob± nosiæ instrukcjê obs³ugi w stylu:
> nie dotykaæ tej wielkiej skrzyni przyczepionej do palety. To jest
> piec. Nie dotykaæ tej bani przyklejonej pod skrzyni± - to jest butla
> ze sprê¿onymi pomys³ami na rok 2008.

Well, Kajtek jest Kajtkiem, a nie systemem informatycznym.

> A czym jest analiza ? Analiza to wyznaczanie granic. Zaznaczanie ich
> czêsto silniej, ni¿ w rzeczywisto¶ci.  Nastêpuj±ca po niej synteza
> nie polega na zamazywaniu tych granic, ale na sk³adaniu w ca³o¶æ
> ograniczonych ale wyrazistych elementów.

Puff...

--
http://www.piotr.dembiñski.prv.pl

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

On Tue, 13 Dec 2005 20:56:13 +0100, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

>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.
>jak konsorcja firm informatycznych, a nie maj±c wyrobione w³asne
>spojrzenie, z doz± zdrowego krytycyzmu.


Proponuje aby Kolega mniej pisal a wiecej studiowal, albowiem
cytowany powyzej paragraf 100 procentowo mija sie z prawda.

A.L.

P.S. Pisze sie "Wirth".

On Sat, 17 Dec 2005 22:20:49 +0100, Przemek Pokrywka
<adres@zastrzezony.com> wrote:


>>
>> P.S. Pisze sie "Wirth".
>
>Dziêkujê za cenn± propozycjê (z której w miêdzyczasie skorzysta³em),
>Panu w zamian proponujê doszlifowanie umiejêtno¶ci cytowania (czy ten
>fragment zdania na koñcu cytatu mia³ byæ jego kontynuacj±, czy te¿
>znalaz³ siê tam przez nieuwagê?). Co do dwu pierwszch zdañ z cytatu
>przyznajê Panu w 100 procentach racjê. Nie zadajê sobie tu trudu
>prostowania, bo zak³adam, ¿e ka¿dy zna prawdziw± historiê i jedynie
>zignorowa³ mój "popis" :)
>
>Ju¿ na studiach nabra³em jakiego¶ niejasnego przeczucia, ¿e czego¶ siê
>jeszcze bêdê musia³ douczyæ... ;)
>
>Pozdrawiam

Uzupelniem brakujay cytat:

"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¶æ...."

... przy czym robie to tylko dla porzadku, albowiem odnosilem sie do
czesci postu pzredstawiajacej historie w niewlascieym swietle.

I spiesze Kolege poinformowac, ze obiektowoc narodzial sie na dlugo
PZRED programowaniem strukturalnym, a mianowicie wraz z jezykiem
Simula 67, ktore to "67" oznacza dwie ostatnie cyfry roku w ktorym w
miare ostatnia (trzecia bodajze) wersja jezyka Simula 67 sie
ukazala.

Zas Historia nie jest bynajmniej subiektywna, jest jak najbardziej
obiecktwna, a znalezc ja mozna na przyklad w materialach (opaslych
dosyc) konferencji ACM na temat historii jezykow programowania. Nei
ma wiec potrzeby dorabiac historii wlasnej.

Zas co do meritum, zastosowanei "obiektowosci" wykracza solidnie
poza "odwzorowanei swiata rzeczywistego", ackolwiek taki wlasnie byl
jej poczatek

A.L.

On Tue, 13 Dec 2005 20:56:13 +0100, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

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

A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...


A.L.

On Sat, 17 Dec 2005 21:55:04 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:

>pdemb@gazeta.pl (=?ISO-8859-2?q?Piotr_Dembiñski?=) napisa³(a):
>
>
>> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
>> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.
>
>>
>> Ta mania odwzorowywania ¶wiata rzeczywistego przez software IMO tr±ci
>> skrzywieniem mened¿ersko-biurokratycznym.
>
>Jezus-Maria.

Moze w Chinach studiowal?... Retoryka jakby znajoma :)

A.L.

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.

On Sun, 18 Dec 2005 01:15:46 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Sat, 17 Dec 2005 22:53:22 +0100, Piotr Dembiñski skrobie:
>> Przemek Pokrywka <adres@zastrzezony.com> writes:
>
>> [...]
>
>> >> 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 ;).
>> >
>> > Trafi³ Pan w samo sedno ;)
>
>> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
>> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.
>
>C i artyzm! Ciebie to chyba pogiê³o.

Rzeczywiscie. Zadzialalo Pierwsze Prawo Grupy pl.comp.objects:
Predzej niz pozniej ludzie zaczna opowiadac bzdury.

A.L.

pdemb@gazeta.pl (=?ISO-8859-2?q?Piotr_Dembiñski?=) napisa³(a):


> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.

>
> Ta mania odwzorowywania ¶wiata rzeczywistego przez software IMO tr±ci
> skrzywieniem mened¿ersko-biurokratycznym.

Jezus-Maria.



A.

--
Wys³ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

A.L. napisa³(a):
> On Tue, 13 Dec 2005 20:56:13 +0100, Przemek Pokrywka
> <adres@zastrzezony.com> wrote:
>
>
>>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.
>>jak konsorcja firm informatycznych, a nie maj±c wyrobione w³asne
>>spojrzenie, z doz± zdrowego krytycyzmu.
>
>
>
> Proponuje aby Kolega mniej pisal a wiecej studiowal, albowiem
> cytowany powyzej paragraf 100 procentowo mija sie z prawda.
>
> A.L.
>
> P.S. Pisze sie "Wirth".

Dziêkujê za cenn± propozycjê (z której w miêdzyczasie skorzysta³em),
Panu w zamian proponujê doszlifowanie umiejêtno¶ci cytowania (czy ten
fragment zdania na koñcu cytatu mia³ byæ jego kontynuacj±, czy te¿
znalaz³ siê tam przez nieuwagê?). Co do dwu pierwszch zdañ z cytatu
przyznajê Panu w 100 procentach racjê. Nie zadajê sobie tu trudu
prostowania, bo zak³adam, ¿e ka¿dy zna prawdziw± historiê i jedynie
zignorowa³ mój "popis" :)

Ju¿ na studiach nabra³em jakiego¶ niejasnego przeczucia, ¿e czego¶ siê
jeszcze bêdê musia³ douczyæ... ;)

Pozdrawiam

Przykro mi, ¿e z powodu ograniczeñ czasowych ustosunkujê siê w tej
chwili jedynie do kwestii drugorzêdnej, choæ Pañski post mnie bardzo
zainteresowa³ i sprowokowa³ do g³êbszego zastanowienia siê nad tematem.

Redart napisa³(a):
>> 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 ;).

Trafi³ Pan w samo sedno ;)

Pozdrawiam

A.L. <alewando@fala56.com> writes:

[...]

> Zas co do meritum, zastosowanei "obiektowosci" wykracza solidnie
> poza "odwzorowanei swiata rzeczywistego", ackolwiek taki wlasnie byl
> jej poczatek

Ta mania odwzorowywania ¶wiata rzeczywistego przez software IMO tr±ci
skrzywieniem mened¿ersko-biurokratycznym.

Przemek Pokrywka <adres@zastrzezony.com> writes:

[...]

>> 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 ;).
>
> Trafi³ Pan w samo sedno ;)

Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.

Dnia Sat, 17 Dec 2005 22:53:22 +0100, Piotr Dembiñski skrobie:
> Przemek Pokrywka <adres@zastrzezony.com> writes:

> [...]

> >> 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 ;).
> >
> > Trafi³ Pan w samo sedno ;)

> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.

C i artyzm! Ciebie to chyba pogiê³o.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Sun, 18 Dec 2005 10:34:03 +0100, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Piotr Dembiñski" <pdemb@gazeta.pl> wrote:
>
>> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
>> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.
>
>Jakies pietnascie lat temu Richard Gabriel mowil: "Mam dobre wiesci i zle
>wiesci. Dobre sa takie, ze za piec lat bedziemy mieli swietny system
>operacyjny i swietny jezyk programowania. Zle sa takie, ze to beda Unix i
>C++."
>
>Heh, minelo pietnascie lat... :-)
>

Dijkstra to mowil. Gabriel has no clue.

A.L.

On Sun, 18 Dec 2005 08:44:44 +0100, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

>A.L. napisa³(a):
>>>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.
>>>
>> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
>
>A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)
>

Po to zeby znac wage Kolegi argumentow. Bo poki co, Kolega opowiada
piramidalne bzdury. Co twierdze na podsatwie mojego doswiadczenia.

A.L.

On Sun, 18 Dec 2005 12:34:01 +0100, pdemb@gazeta.pl (Piotr
Dembiñski) wrote:

>Przemek Pokrywka <adres@zastrzezony.com> writes:
>
>[...]
>
>>> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
>>
>> A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)
>
>AL ju¿ tak ma.  Poczytaj archiwum.

No to gratulacje. Kolega D. doswiadcza zaszczytu wizytowania mojego
KF. Na rok. Za "wtrety personalne"

A.L.

A.L. napisa³(a):
>>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.
>>
> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...

A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)

Sposoby organizacji projektu informatycznego to temat na osobn± grupê
dyskusyjn±. Tam proponowana przez Pana wymiana do¶wiadczeñ mog³aby mieæ
(w niektórych wypadkach) sens. Postuj±c na pl.comp.objects interesujê
siê w pierwszej kolejno¶ci obiektami.

Pisz±c w skrócie: NTG

A to, ¿e odnios³em siê na tej grupie do tematyki organizacji projektu,
to tylko po to, ¿eby podkre¶liæ, ¿e s± w tej dziedzinie tak¿e odmienne
zdania, ni¿ te mimochodem niejako "przemycane" w postach nt. obiektów
przez niektórych moich Szacownych Adwersarzy.

Pozdrawiam

"Piotr Dembiñski" <pdemb@gazeta.pl> wrote:

> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.

Jakies pietnascie lat temu Richard Gabriel mowil: "Mam dobre wiesci i zle
wiesci. Dobre sa takie, ze za piec lat bedziemy mieli swietny system
operacyjny i swietny jezyk programowania. Zle sa takie, ze to beda Unix i
C++."

Heh, minelo pietnascie lat... :-)


mp

A.L. <alewando@fala56.com> writes:

[...]

>>> Ta mania odwzorowywania ¶wiata rzeczywistego przez software IMO
>>> tr±ci skrzywieniem mened¿ersko-biurokratycznym.
>>
>>Jezus-Maria.
>
> Moze w Chinach studiowal?...

To jest ofkors moje w³asne, nie profesorskie.

Przemek Pokrywka <adres@zastrzezony.com> writes:

[...]

>> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
>
> A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)

AL ju¿ tak ma.  Poczytaj archiwum.

A.L. napisa³(a):
> >> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
> >
> >A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)
>
> Po to zeby znac wage Kolegi argumentow. Bo poki co, Kolega opowiada
> piramidalne bzdury. Co twierdze na podsatwie mojego doswiadczenia.

To bardzo ciekawe, ¿e Pana zdaniem opowiadam "piramidalne" bzdury -
wskazuje to na to, ¿e ma Pan zupe³nie inne do¶wiadczenia, co mo¿e
byæ doskona³ym pretekstem do ich wymiany. Z drugiej strony by³bym
bardzo ciekaw konkretnego wskazania owych "bzdur" i tych ich cech,
które pozwalaj± przypisaæ im atrybut "piramidalno¶ci".

Tak, czy owak, do ocenienia wagi argumentów powinna wystarczyæ
znajomo¶æ ich tre¶ci, a nie informacje na temat wyg³aszaj±cej je
osoby.

A.L. <alewando@fala56.com> writes:

> On Sun, 18 Dec 2005 12:34:01 +0100, pdemb@gazeta.pl
> (Piotr Dembiñski) wrote:
>
>>Przemek Pokrywka <adres@zastrzezony.com> writes:
>>
>>[...]
>>
>>>> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
>>>
>>> A mo¿na wiedzieæ, po co Koledze to wiedzieæ? :)
>>
>>AL ju¿ tak ma.  Poczytaj archiwum.
>
> No to gratulacje. Kolega D. doswiadcza zaszczytu wizytowania mojego
> KF. Na rok. Za "wtrety personalne"

Prosz.  Oczekujê tego samego od ca³ej Pañskiej koterii.

Dnia Sun, 18 Dec 2005 08:11:21 -0600, A.L. skrobie:
> On Sun, 18 Dec 2005 10:34:03 +0100, "Michal Przybylek"
> <mrp@neostrada.pl> wrote:

> >"Piotr Dembiñski" <pdemb@gazeta.pl> wrote:
> >
> >> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
> >> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.
> >
> >Jakies pietnascie lat temu Richard Gabriel mowil: "Mam dobre wiesci i zle
> >wiesci. Dobre sa takie, ze za piec lat bedziemy mieli swietny system
> >operacyjny i swietny jezyk programowania. Zle sa takie, ze to beda Unix i
> >C++."
> >
> >Heh, minelo pietnascie lat... :-)
> >

> Dijkstra to mowil. Gabriel has no clue.

Szkoda, ¿e nie do¿y³...


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"A.L." <alewando@fala56.com> wrote:

> >> Z drugiej strony: s± w komputerach projekty zrobione tak dobrze,
> >> ¿e mo¿na siê w nich dopatrywaæ artyzmu, np. Unix, OpenGL albo C.
> >
> >Jakies pietnascie lat temu Richard Gabriel mowil: "Mam dobre wiesci i zle
> >wiesci. Dobre sa takie, ze za piec lat bedziemy mieli swietny system
> >operacyjny i swietny jezyk programowania. Zle sa takie, ze to beda Unix i
> >C++."
> >
> >Heh, minelo pietnascie lat... :-)
> >
>
> Dijkstra to mowil. Gabriel has no clue.

Mozliwe.

W kazdym razie zdumiewajace. Tak trafnoscia jak i tym po ilu latach jeszcze
obowiazuje...


mp

Redart napisa³(a):
> 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.

Odniosê siê w tym po¶cie tylko do tego zagadnienia

> Spójrzmy na typowy, du¿y system:
[...]
Tutaj obrazowo przedstawia Pan egzemplarz systemu bankowego, k³ad±c
szczególny akcent na generowane przezeñ wszechstronne, przekrojowe
raporty (których u¿yteczno¶ci ani ¶ni mi siê podwa¿aæ).

> POWSTAJE WIEC PIERWSZE PYTANIE: Czy to oznacza, ¿e obiekt "klient" ma
> mieæ w sobie
> metody do wywo³ywania 50% raportów systemu ?

Jak Pan zapewne podejrzewa, moja odpowied¼ tak¿e bêdzie negatywna. Jej
uzasadnienie za to bêdzie ró¿ne od Pañskiego, a w skrócie streszcza je
artyku³ dostêpny pod adresem:

http://www.martinfowler.com/bliki/ReportingDatabase.html

Do raportowania stosuje siê te¿ czasem hurtownie danych

Korzystaj±c z chwilki wolnego czasu, pragnê ustosunkowaæ siê do
nastêpnych fragmentów Pana bardzo interesuj±cej wypowiedzi.
Zgadzam siê z Panem, ¿e prowadzenie szerokiej dyskusji w jednym w±tku
jest trudne, dlatego te¿ odpowied¼ na drug± czê¶æ postu opublikujê ju¿
pod innym tematem.

Redart napisa³(a):
>>> 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.

Przedstawiony przez Pana przyk³ad daje siê bardzo ³adnie zaprojektowaæ z
wykorzystaniem obiektów, a nie tylko przy pomocy "m±drego algorytmu"
(skanera) i "g³upiej struktury danych" (programu ¼ród³owego).
W rozwi±zaniu obiektowym u¿y³bym wzorca Builder (GoF). Tre¶æ programu
potraktowa³bym jako swojego rodzaju "zserializowan±" reprezentacjê
pojedynczego obiektu (jednostki kompilacji), sk³adaj±cego siê z wielu
innych z³o¿onych (klasy, metody) i prostych (liczby, identyfikatory)
podobiektów. Moim zdaniem, taki obiektowy projekt oferuje lepsze
mo¿liwo¶ci zarz±dzania sob± samym (dziêki swoi¶cie pojêtemu zastosowaniu
metody "dziel i rz±d¼).

Równie¿ przypadek cz³owieka, który operuje narzêdziem nie wydaje mi siê
z marszu idealnym kandydatem do zastosowania projektu typu "algorytmy +
struktury danych" - nie kwestionuj±c przy tym faktu, ¿e ca³a
inteligencja potrzebna do wykonania operacji w³a¶ciwa jest
_cz³owiekowi_. Wad± zamodelowania tej inteligencji przez algorytm
(pozbawiony w³asnego stanu) jest nieuwzglêdnienie np. stanu
emocjonalnego cz³owieka, przez który mo¿e on operowaæ narzêdziem
nieprecyzyjnie, jak równie¿ jego umiejêtno¶ci w pos³ugiwaniu siê tym
narzêdziem. Projektuj±c obiektowo, cz³owieka zamodelowa³oby siê jako
obiekt z³o¿ony z innych obiektów, jak jego nawyki, umiejêtno¶ci oraz
stan emocjonalny, z których ka¿dy mia³by swój udzia³ w operowaniu
narzêdziem.

Jeszcze odno¶nie podzia³u logiki (inteligencji) pomiêdzy ludzi a
narzêdzia - rzadko bywa, ¿e skupienie ca³ej logiki w obiekcie nadrzêdnym
(cz³owiek) kontroluj±cym obiekt podrzêdny (narzêdzie) ma najwiêkszy
sens. Najczê¶ciej po¿±dane jest, aby narzêdzie wykaza³o siê mniejsz± lub
wiêksz± inteligencj±, ¿eby odci±¿yæ cz³owieka od uci±¿liwego pamiêtania
o najdrobniejszych szczegó³ach. We¼my ekspes do kawy - wystarczy
nacisn±æ w nim przycisk, by do podstawionej fili¿anki nala³ on
aromatycznej kawy ze ¶wie¿o zmielonych ziaren. Jest to narzêdzie
inteligentne, s³u¿±ce t± inteligencj± cz³owiekowi, który nie musi sam
mieliæ ziaren, dodawaæ ich w odpowiedniej proporcji do fili¿anki,
gotowaæ wody, by zalaæ ni± kawê i odfiltrowywaæ fusy. Byæ mo¿e czynno¶ci
te potrafi± daæ wiele rado¶ci i relaksu osobie dysponuj±cej wolnym
czasem, a i kawa mo¿e smakowaæ lepiej, bo do jej przygotowania w³o¿ono
serce, ale projektantowi spiesz±cemu siê wypróbowaæ nowe pomys³y bêd±
tylko kul± u nogi.
I tak dla mnie, co prawda skupienie ca³ej logiki w obiekcie nadrzêdnym
bywa uzasadnione w okre¶lonych przypadkach, to jednak na codzieñ jest to
zjawisko niekorzystne - bo obiekt nadrzêdny zmuszony jest do zajmowania
siê niepotrzebnymi mu detalami.

>
> Do kompilatora zintegrowanego ze ¶rodowiskiem uruchomieniowym jednak
> jeszcze baaardzo daleko.

to prawda - jaki jednak ma z tego p³yn±æ wniosek?

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

Tak jest. Jak ju¿ jednak wspomnia³em odrobinê wy¿ej, inteligencja
narzêdzia bywa najczê¶ciej pomocna (choæ w wyj±tkowych sytuacjach bywa
te¿, ¿e przeszkadza).

On Sun, 12 Oct 2008 21:31:52 +0200, "Filip Sielimowicz"
<sielim@poczta.onet.pl> wrote:

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

Ciekawe komu Pan odpowiada i na co?...

A.L.

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

U�ytkownik "A.L." <alewando@zanoza.com> napisa� w wiadomo�ci
news:96s4f4lkhg7v426k2usjgnr873p076961b@4ax.com...
> On Sun, 12 Oct 2008 21:31:52 +0200, "Filip Sielimowicz"
> <sielim@poczta.onet.pl> wrote:
>
>>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.
>>
>
> Ciekawe komu Pan odpowiada i na co?...

Uznajmy zo za pomy�k� ... Czy�ci�em folder z wersjami roboczymi.
W�tek jest stary, u mnie w domu jeszcze istnieje w ca�o�ci, w pracy
widz� tyle samo co Pan - czyli nic ... ;)