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.

> Można przewidzieć, że
> przerabianie programu do wyceny instrumentów finansowych może np.
> uwzględnić inne rodzaje instrumentów finansowych i inne metody wyceny
> niż oryginalnie przewidywano.
Zbliżamy się do konkretnych przykładów - fajnie.


> Problem jest taki, że jeśli spróbujesz zaprojektować swoją hierarchię
> typów tak, żeby uwzględnić wszelkie możliwe rodzaje instrumentów
> finansowych, to wykonasz gigantyczny kawał nikomu nie potrzebnej roboty,
> ale też stworzysz gorszy program, bo bardziej skomplikowany, trudniejszy
> do zrozumienia, a zatem łatwiej będzie popełnić w nim błąd, i trudniej
> go zmienić np. uwględniając instrument finansowy, którego nie
> uwzględniłeś w pierwotnym projekcie (bo, powiedzmy, jeszcze nie istniał).
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,
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.


> Natomiast jeśli chodzi o przerabianie programu do wyceny instrumentów
> tak, żeby wyceniał nowe instrumenty, żeby stosował nowe metody wyceny,
> czy żeby cośtam jeszcze robił z tymi instrumentami czy wycenami, czego
> pierwotnie nie przewidziałeś, to refaktoryzacja w celu uwzględnienia
> danej funkcjonalności nie musi być koszmarem, pod warunkiem, że się
> stosuje odpowiednie praktyki.
Zgadzam się że nie musi. Dużo zależy od dobrego projektu, ale od
szczęścia też nie mało. Skoro od szczęścia niemało to może dobrze
się składa, mamy dzięki temu grunt na którym języki programowania mogą
pomagać.


> No i oczywiście może tak być, że ta refaktoryzacja jest dużo prostsza,
> przyjemniejsza i mniej podatna na błędy jeśli stosujesz dynamiczny
> system typów.
Wiem od początku do czego zmierzasz, problem w tym, że nie wiem dlaczego
masz rację.


> 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ć. Tak czy inaczej nie widzę tego że trzeba wszystko
przerabiać. O jakie dokładnie przeróbki chodzi z tymi dinozaurami?
Mam nadzieję że nie piszesz tego w nawiązaniu do naszych dawnych
rozmów, kiedy to ja pisałem wręcz o całkowitym przepianiu programu od
nowa. Wtedy pisałem tak w zupełnie innym kontekście, a mianowicie w
kontekście ekstremalnej optymalizacji.


Wracając do Twojego przykładu z dinozaurami. Przykład jest dobry, ale
jeszcze za mało konkretny. 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. Algorytmy na nowych cechach Ptaka trzeba dopisać bez względu na
użyty język.


> 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.
W sumie może być większy zysk czasu z powodu mniejszego nakładu pracy
w trakcie uruchamiania.

Pozdrawiam