W dniu 2014-02-13 04:03, A.L. pisze:
> On Wed, 12 Feb 2014 19:20:55 +0100, "intuicjonista"
> <c...@g...pl> wrote:
>
>>
>> Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:qr3nf9pqolk7p9uloos3mv4jnd69knf0pc@4ax.com...
>>> On Wed, 12 Feb 2014 14:57:03 +0100, "intuicjonista"
>>> <c...@g...pl> wrote:
>> ...
>>>> facet mówi w prost - paradygmat odwzorowania
>>>> ( wybranego fragmentu) rzeczywistosci w postaci
>>>> rozbudowanej hierarchi klas jest niefektywny (niesprawdził sie).
>>>
>>> To facio zwyczajnie pieprzy. Znanych jest mnostwo przykladow gdy
>>> sparwdzil sie doskonale.
>>
>> nie bardzo pasuje mi rola jego adwokata
>> (zwłaszcza,ze słuchałem tego jednym uchem) ale ...
>>
>> zapewne można podać również wiele przykładów gdzie się
>> taki model nie sprawdził - lub był zwyczajnie niewygodny
>>
>
> Mozna. Ale z tego nie wynika ze "OOp is dead". Jak pisalem wyzej, OO
> jest JEDNYM SZE SPOSOBOW traktowania rzeczywistosci, i powinien byc
> uzywany wtedy gdy spelnai swa role. Nei zawsze spelnia, wiec w wielu
> prupadkach sie go nei stosuje
>

A ściślej - nie powinno stosować. Ale bywa, że ludzie nie znają nic
innego, albo mają sentyment/chęć podążania za "modą" tak duży, że użyją
narzędzia, które nie pasuje. Przy odpowiednio dużej "propagandzie"
dowolnego podejścia staje się ono dominujące.

[...]
>> wskazuje na to co ostatnio się
>> robi popularne :
>> elastyczność, lekkie klasy,interfejsy, iteratory,kolekcje,
>> properties , lambda-expression,...?
>>
>
> Alez to wszystko jest totalnie ortogonalne do OO, nei ma nic wspolnego
> z OO, ani OO nie zastapi.

Chyba jednym ze źródeł nieporozumienia jest mieszanie modelu obiektowego
z implementacją w językach, które mają pojęcie klasy i obiektu. Pierwsze
to strategia, drugie - taktyka. Modelować można OO, implementować C.
Najgorzej, gdy ktoś się upiera, że pojęcia z modelu mają być 1:1
przenoszone do implementacji. Praktyka pokazuje, że od pewnego poziomu
warto tworzyć klasy, które z elementami modelu nie koniecznie mają
związek, np. podzielenie funkcjonalności jednego obiektu, który jest
tylko agregatem takich "obiektów w sensie implementacji", czy stany
obiektu jako oddzielne klasy.

Innymi słowy - modelowanie/projektowanie obiektowe a programowanie
obiektowe to zupełnie rozłączne sprawy.

--
Paweł Kierski
n...@p...net