Transfer objects
Przemek Pokrywka
Bo mi się wydaje, że nie
Przemek
Robert Perlinski
> 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
> 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
Robert Perlinski
>> 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
Grzesiek G.
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
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
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,
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
Michał Słocinski
> 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ł
Filip Sielimowicz
Użytkownik "Michał Słocinski" <nob...@nowhere.com> napisał w wiadomości
news:slrndpo7kg...@localhost.localdomain...
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.
Piotr Dembiński
[...]
> 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
Filip Sielimowicz
Użytkownik ""Piotr Dembiński"" <pd...@gazeta.pl> napisał w wiadomości
news:87y82ra...@hector.domek...
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.
Piotr Dembiński
> Użytkownik ""Piotr Dembiński"" <pd...@gazeta.pl> napisał w wiadomości
> news:87y82ra...@hector.domek...
>> "Filip Sielimowicz" <sie...@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
Przemek Pokrywka
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
Redart
Użytkownik "Przemek Pokrywka" <ad...@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.
A.L.
<ad...@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.
>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".
Przemek Pokrywka
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
Przemek Pokrywka
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.
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.
Piotr Dembiński
[...]
> 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.
Piotr Dembiński
[...]
>> 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.
Aleksander Galicki
> 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.
<ad...@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.
A.L.
<tre...@WYTNIJ.gazeta.pl> wrote:
>pd...@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.
Sektor van Skijlen
> Przemek Pokrywka <ad...@zastrzezony.com> writes:
> [...]
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"
A.L.
<etho...@pl.wp.spamu.lubie.nie.invalid> wrote:
>Dnia Sat, 17 Dec 2005 22:53:22 +0100, Piotr Dembiński skrobie:
>> Przemek Pokrywka <ad...@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.
Przemek Pokrywka
>>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
Michal Przybylek
> 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
Piotr Dembiński
[...]
>>> 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.
Piotr Dembiński
[...]
>> A mozna wiedzziec jakie jest Kolegi "doswiazcznia"?...
>
> A można wiedzieć, po co Koledze to wiedzieć? :)
AL już tak ma. Poczytaj archiwum.
A.L.
Dijkstra to mowil. Gabriel has no clue.
A.L.
A.L.
<ad...@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.
A.L.
No to gratulacje. Kolega D. doswiadcza zaszczytu wizytowania mojego
KF. Na rok. Za "wtrety personalne"
A.L.
Piotr Dembiński
Sektor van Skijlen
Szkoda, że nie dożył...
przemysla...@gmail.com
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.
Michal Przybylek
> >> 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
Przemek Pokrywka
> 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
Przemek Pokrywka
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).
Filip Sielimowicz
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
ś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
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
Ufff ...
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 ;)))
A.L.
<sie...@poczta.onet.pl> wrote:
>Użytkownik "Przemek Pokrywka" <ad...@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.
Filip Sielimowicz
Użytkownik "A.L." <alew...@zanoza.com> napisał w wiadomości
news:96s4f4lkhg7v426k2...@4ax.com...
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 ... ;)