On 09/02/2013 18:53, M.M. wrote:
> W dniu sobota, 9 lutego 2013 18:45:20 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
>> fianasowych na program do sterowania samolotem.
> No więc jeśli rozmawiamy o przerabianiu tego typu, to z całym
> szacunkiem, ale nie rozumiem dlaczego w Java/C++ jest znacznie
> trudniej.

Bo trzeba mieć hierarchię typów dobrze mapującą kawałek dziedzinę i
funkcjonalność programu. Zmienia się dziedzina i/lub funkcjonalność,
może się okazać, że potrzebna nam hierarchia jest zupełnie inna. W
związku z tym potencjalnie każdem miejsce, gdzie używane są te typy,
trzeba zmienić.

> Nie musi być tak, że program bardziej ogólny jest trudniejszy w
> analizie, zaprojektowaniu i implementacji niż program wyspecjalizowany.
> Powiedziałbym wręcz, że zwykle proście się pisze, jeśli od razu,
> nawet w wyspecjalizowanym programie, robi się dobre abstrakcje. Owszem,

Łatwiej zrobić prostszy program z dobrymi abstrakcjami niż skomplikowany
program z dobrymi abstrakcjami. Dobre abstrakcje nie oznaczają, że
musisz uwzględnić wszystko, czego twój program nie musi robić ani
wiedzieć. Wręcz przeciwnie, mogą od tego wszystkiego wyabstrahować.

> w prostym/wyspecjalizowanym programie, jest trochę szybciej jeśli
> niechlujnie sobie wrzucimy dane do kilku struktur/tablic. Zdarza mi
> się samemu tak niechlujnie pisać. Jednak takie programowanie naraża
> nas na straty czasu w trakcie debugowania. Narzut czasu na kilka
> definicji abstrakcyjnych klas zwróci się w postaci mniejszej ilości
> błędów.

Prostota to nie niechlujność.

>> PIeczołowice zaprojektowałeś system typów opierając się na założeniu, że
>> dinozaur to rodzaj gada, a tu nagle się okazuje, że niektóre dinozaury,
>> które musisz obsłużyć w swoim systemie, w myśl twojego systemu typów
>> wcale nie są gadami tylko ptakami. W statycznym systemie typów musisz
>> wszystko teraz przerabiać, przy dynamicznym typowaniu nie przejmujesz
>> się - jeśli masz funkcję obsługującą dinozaura, to możesz tam wrzucić
>> dinozaura, niezależnie od tgo, czy jest gadem czy nie.
> Zgadza się poza najważniejszym: "wszystko przerabiać". Zresztą
> nie wiem... może piszesz o jakimś przypadku w którym naprawdę wszystko
> trzeba przerabiać.

Raz trzeba przerabiać mniej, raz więcej. W praktyce niekiedy trzeba
przerabiać na tyle dużo, że zamiast porządnie zrefaktoryzować wpycha się
dziedzinę w niepasujący stary model, sztukując go tak, żeby działało. W
powyższym przykładzie możesz to sobie wyobrazić tak, że ktoś decyduje,
że najprościej będzie zaimplementować zmianę zakładając, że klasa Gad
nie zawsze reprezentuje gady, więc wstawia się nową metodę
'jestPrawdziwymGadem()'. O przykrych konsekwencjach takiego działania
nie muszę nawet wspominać.

> Tak czy inaczej nie widzę tego że trzeba wszystko
> przerabiać. O jakie dokładnie przeróbki chodzi z tymi dinozaurami?

No, masz funckją przyjmującą obiet typu Gad (albo metodę tego typu),
która ci wcześniej obsługiwała dinozaury i w iluś miejscach programu
korzystasz z tej właściwości, a tu nagle się okazuje, że tak się nie da
i musisz wymyśleć coś innego.

> Mam nadzieję że nie piszesz tego w nawiązaniu do naszych dawnych
> rozmów,

Nie, absolutnie do niczego nie nawiązuję.

> Wracając do Twojego przykładu z dinozaurami. Przykład jest dobry, ale
> jeszcze za mało konkretny.

Z założenia każdy przykład, jaki można podać w takiej dyskusji będzie
mało konkretny. Konkretne przykłady dotyczą mocno rozbudowanych
programów ze skomplikowanymi hierarchiami typów o dziesiątkach lub
setkach składowych, mapującymi skomplikowane dziedziny, których
zrozumienie wymaga wielu lat nauki i praktyki.

Czy jeśli ci na przykład powiem, że takim przykładem jest wprowadzenie
obsługi transakcji typu taikeshu do systemu wypożyczania papierów
wartościowych, to odpowiesz mi "aha, no faktycznie, teraz rozumiem", czy
"bzdury opowiadasz, refaktoiryzacja dobrze zaprojektowanego modelu
danych wypożyczania papierów wartościowych tak, żeby obsługiwać
transakcje taikeshu nie powinna nastręczać żadnych trudności"?

> Dlaczego w Java/C++ nie można takiego
> Dinozaura przerobić na klasę bazową, a następnie z niej wyprowadzić klas
> Gad i Ptak? Stare algorytmy przecież zadziałają tak samo jak działały do
> tej pory.

Nie zadziałają w ogóle, bo kompilator odmówi ich skompilowania, krzycząc
że spodziewa się Gada, a ty mu przekazujesz Dinozaura. Po poprawieniu
pięciuset takich błędów kompilatora, przy 501-szym zdajesz sobie sprawę,
że twoja nowa hierarchia też jest niedobra, bo nie wszystkie gady są
dinozaurami.

>> Zwłaszcza jeśli wymaganą logikę możesz zaimplementować w tydzień, a
>> przez kolejne trzy tygodnie będziesz uciszał krzyki kompilatora.
> Mój przykład z łodzią, samochodem i amfibią zamieniłeś na prosty
> program do instrumentów finansowych i skomplikowany program do instrumentów
> finansowych. Więc ja Twoje trzy tygodnie krzyków zamieniam na kilka
> godzin w stosunku tygodnia roboty, a przy okazji tych kilku godzin
> kompilator wychwyci błędy, które wyszłyby dopiero w trakcie uruchamiania.

Ale przecież ja nie przeczę, że to, co pisałeś o samochodach i amfibiach
jest prawdą. Może i jest - nieznam się na tym. Moja teza dotyczy czegoś
innego - nie samochodów i amfibii, tylko programów komputerowych.