W dniu 2010-10-17 08:13, Sebastian Biały pisze:
> On 2010-10-17 02:53, Wojciech Jaczewski wrote:
>> Czemu tak upierasz się przy kodzie "obiektowym".
>
> Poniewaz nie ma inne alternatywy dla dużych projektów jak miec porządek.
> Obiekty go zapewniają i są dostepne w jezyku. Zapewniają też wiele
> więcej przy prawidłowym projekcie.
>
>> Przecież "obiektowy" wcale
>> nie jest synonimem "dobry", czy "przejrzysty".
>
> Zależy jaki obiektowy. Dobry obiektowy jest zdecydowanie bardziej
> przejrzysty, szczególnie jak używa wzorców. OnClick nie jest "wzorcem"
> dobrym, jednak Delphi tak silnie go sugeruje że wielu nie może się
> oprzeć pokusie i pisze kod o takiej jakości.

>
>> Inna rzecz, że pojęcie "obiektowy" jest przez różnych ludzi
>> różnie rozumiane...
>

Podkreslibym te slowa o pokusie, tak jest jak cos jest (pozornie) latwe.

W rdzeniu VCL (Delphi/BCB) sa fajne zamysly obiektowe, moze utrzymane w
pierwszej fali OOP (akcent na dziedzczenia, przed wzorcami), ale sa.
Przypomnial bym TXxxxxCustom jako przedostatni poziom dziedziczenia,
rozumie ze jest to fajna propozycja do programisty 'Odziedzicz sobie
swiadomie jak Ci trzeba'. Jest kilka innych pozytywnych rzeczy.
(Sa wpadki, np brak abstrakcyjnego Query, ale to sie rodzilo w czasach
plikowych baz)
jednak przyjecie tego w spolecznosci jest niemal zerowe. Rzecz ciekawa,
owa koncepcja z XxxxxCustom jest tylko w starych seriach komponentow,
nie wystepuje w nowych. Jak ja rozumiem, nikomu nie byla potrzebna. Nikt
juz pozniej nie myslal by hierarchie klas byly dobrze zaprojektowane -
komponenty mialy byc "ladne" i tyle.

Elementy dojrzalego OOP (wzorce, np swiadomie promowane fabryki,
strategie - pierwsze z brzegu skojarzenie - choc okazji do
fabryk/strategii jest sporo) nie istnieja. I chyba juz z tego nie
bedzie, spolecznosc tego nie chce i nie pojmie (w swojej sredniej). I
musieli by zerwac kompatybilnosc.