🚀 go-pugleaf

"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 

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

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

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

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

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

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.

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.

pdemb@gazeta.pl (=?ISO-8859-2?q?Piotr_Dembi=F1ski?=) 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/

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=F1ski?=) 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.

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

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.

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

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

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