On 08/02/2013 17:52, M.M. wrote:
> W dniu piątek, 8 lutego 2013 18:14:45 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
>> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
> Moim zdaniem jest to kwestia szczęścia. Jeśli nie odgadniemy jak
> projekt w przyszłości będzie się rozwijał, to w każdym języku
> dogłębna (nie kłóćmy się o zmianę int na double - to niezauważalnie mały
> nakład pracy) refaktoryzacja staje się koszmarem.
> Przerabianie samochodu albo łodzi na amfibię zawsze jest trudniejszym
> zadaniem niż produkcja amfibii od zera.

Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
fianasowych na program do sterowania samolotem. 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.

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ł).

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.

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.

> Znowu muszę zapytać jak zdarta płyta: jaki jest przykład takiej refaktoryzacji
> która będzie trudna w C++, a łatwa w Pythonie, Rubym i reszcie.

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.

> Mnie się
> wydaje to bardzo pomocne gdy kompilator C++ krzyczy już w trakcie
> kompilacji że się typy nie zgadzają.

Zwłaszcza jeśli wymaganą logikę możesz zaimplementować w tydzień, a
przez kolejne trzy tygodnie będziesz uciszał krzyki kompilatora.