🚀 go-pugleaf

Korzystając z chwilki wolnego czasu, pragnę ustosunkować się do 
następnych fragmentów Pana bardzo interesującej wypowiedzi.
Zgadzam się z Panem, że prowadzenie szerokiej dyskusji w jednym wątku 
jest trudne, dlatego też odpowiedź na drugą część postu opublikuję już 
pod innym tematem.

Redart napisał(a):
>>> To nie ma po prostu żadnego przełożenia na rzeczywistość.
>>>
>>> Mamy nóż i mamy chleb.
>>
>> [...]
>>
>> To dosyć oryginalne obiekty w systemie informatycznym :)
> 
> 
> No to weźmy program źródłowy i skaner(analizator syntaktyczny).
> Analogia jest bardzo bliska - drugi "umie" ciąć ten pierwszy - i
> robi to wg. bardzo prostych, w dużym stopniu niezależnych od cietej
> materii zasad: wyłapuje liczby, identyfikatory a tnie np. po białych 
> znakach.

Przedstawiony przez Pana przykład daje się bardzo ładnie zaprojektować z 
wykorzystaniem obiektów, a nie tylko przy pomocy "mądrego algorytmu" 
(skanera) i "głupiej struktury danych" (programu źródłowego).
W rozwiązaniu obiektowym użyłbym wzorca Builder (GoF). Treść programu 
potraktowałbym jako swojego rodzaju "zserializowaną" reprezentację 
pojedynczego obiektu (jednostki kompilacji), składającego się z wielu 
innych złożonych (klasy, metody) i prostych (liczby, identyfikatory) 
podobiektów. Moim zdaniem, taki obiektowy projekt oferuje lepsze 
możliwości zarządzania sobą samym (dzięki swoiście pojętemu zastosowaniu 
metody "dziel i rządź).

Również przypadek człowieka, który operuje narzędziem nie wydaje mi się 
z marszu idealnym kandydatem do zastosowania projektu typu "algorytmy + 
struktury danych" - nie kwestionując przy tym faktu, że cała 
inteligencja potrzebna do wykonania operacji właściwa jest 
_człowiekowi_. Wadą zamodelowania tej inteligencji przez algorytm 
(pozbawiony własnego stanu) jest nieuwzględnienie np. stanu 
emocjonalnego człowieka, przez który może on operować narzędziem 
nieprecyzyjnie, jak również jego umiejętności w posługiwaniu się tym 
narzędziem. Projektując obiektowo, człowieka zamodelowałoby się jako 
obiekt złożony z innych obiektów, jak jego nawyki, umiejętności oraz 
stan emocjonalny, z których każdy miałby swój udział w operowaniu 
narzędziem.

Jeszcze odnośnie podziału logiki (inteligencji) pomiędzy ludzi a 
narzędzia - rzadko bywa, że skupienie całej logiki w obiekcie nadrzędnym 
(człowiek) kontrolującym obiekt podrzędny (narzędzie) ma największy 
sens. Najczęściej pożądane jest, aby narzędzie wykazało się mniejszą lub 
większą inteligencją, żeby odciążyć człowieka od uciążliwego pamiętania 
o najdrobniejszych szczegółach. Weźmy ekspes do kawy - wystarczy 
nacisnąć w nim przycisk, by do podstawionej filiżanki nalał on 
aromatycznej kawy ze świeżo zmielonych ziaren. Jest to narzędzie 
inteligentne, służące tą inteligencją człowiekowi, który nie musi sam 
mielić ziaren, dodawać ich w odpowiedniej proporcji do filiżanki, 
gotować wody, by zalać nią kawę i odfiltrowywać fusy. Być może czynności 
te potrafią dać wiele radości i relaksu osobie dysponującej wolnym 
czasem, a i kawa może smakować lepiej, bo do jej przygotowania włożono 
serce, ale projektantowi spieszącemu się wypróbować nowe pomysły będą 
tylko kulą u nogi.
I tak dla mnie, co prawda skupienie całej logiki w obiekcie nadrzędnym 
bywa uzasadnione w określonych przypadkach, to jednak na codzień jest to 
zjawisko niekorzystne - bo obiekt nadrzędny zmuszony jest do zajmowania 
się niepotrzebnymi mu detalami.

> 
> Do kompilatora zintegrowanego ze środowiskiem uruchomieniowym jednak
> jeszcze baaardzo daleko.

to prawda - jaki jednak ma z tego płynąć wniosek?

> Zupełnie ktoś inny decyduje o tym , co dokładnie
> kroić (podstawia chleb pod nóż) i kiedy. A także odpowiada na pytania
> "po co", "co dalej".

Tak jest. Jak już jednak wspomniałem odrobinę wyżej, inteligencja 
narzędzia bywa najczęściej pomocna (choć w wyjątkowych sytuacjach bywa 
też, że przeszkadza).