On 12/04/2011 20:17, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>>
>> Nie wiem co stosowałeś, jak i dlaczego, ale jeśli chcesz powiedzieć, że
>> techniki obiektowe to taki właśnie przerost formy nad treścią, którego
>> uczą na uczelniach, ale w praktyce komercyjnej nie mają innego
>> znaczenia, to nie da się tego nazwać inaczej niż bzdurą.
>
> Nie twierdzę, że się ich nie stosuje, tylko że często się je stosuje
> niepotrzebnie.

Być może. Ale ja z kolei twierdzę, że jest to mniej częste, niż ci się
wydaje.

> A da się też robić dobre programy bez nich.

Pytanie czy równie dobre i czy równie sprawnie. Ja uważam, że nie.

> Oczywiście, jeśli w jakiejś firmie kierownictwo się uprze, że programy mają
> być obiektowe, to inaczej nie można.
> Na szczęście nie wszędzie jest taki wymóg (nie znam statystyk).

Statystyke też nie znam, ale na ile się orientuję, ogromna większość
oprogramowania w prawie wszystkich dziedzinach stosuje w jakimś stopniu
techniki obiektowe.

> U mnie na
> szczęście zagadnienia dają się podzielić na osobne, działające wspólnie w
> systemie procesy, więc nie trzeba prowadzić wojen o strukturę programu -
> każdy wykonuje taką, jaka mu pasuje.

Pozwolę sobie w związku z tym zauważyć dwie rzeczy: po pierwsze, sporo
oprogramowania nie jest tak pisane. Gdyby specjalnie w ten sposób
wszystko projektować żeby unikać sytuacji kiedy kod jednego programisty
jest wykorzystywany przez kod innego programisty, to bardzo negatywnie
wpłynęłoby to na wydajność i niezawodność tego oprogramowania.

Po drugie nawet tam, gdzie projektuje się właśnie w ten sposób, często
dąży się do poprawy wydajności i niezawodności przez code reuse. I
techniki obiektowe bywają bardzo przydatne do tych celów.

>> rzeczywistości większość oprogramowania komercyjnego tworzy się z
>> użyciem technik obiektowych i mają one kolosalne znaczenie dla
>> wydajności tworzenia programów i ich niezawodności.
>
> W pozytywny wpływ technik obiektowych na niezawodność zwyczajnie nie wierzę.
> Z moich obserwacji, awaryjność moich programów powstałych po odrzuceniu
> większości technik obiektowych wyraźnie spadła, natomiast ogromnie poprawiła
> się elastyczność - w sensie, że pojawiają się nowe wymagania i trzeba
> program szybko do nich dostosować. Tworząc jakieś hierarchie obiektów,
> ciągle natrafia się na coś, czego się nie przewidziało i trzeba prawie
> całkowicie przebudowywać program.

A według mnie w 99 przypadkach na 100 takie opinie wynikają ze słabego
zrozumienia i nieumiejętności efektywneego posługiwania się technikami
obiektowymi, w dużej części właśnie wynikające z tego, że ktoś się sam
nauczył i potem nie chciał zmieniać przyzwyczajeń. Oczywiście nie mówię,
że to ty. Może i nawet jesteś tym 1 przypadkiem na 100, ale nawet w tym
przypadku zaleta technik obiektowych jest taka, że jesteś 1 przypadkiem
na 100.

Oczywiście istnieją nie-obiektowe alternatywy dla rozwiązań, które dają
techniki obiektowe, np. w językach takich jak Lisp, ale też mają swoje
wady, np. brak silnego systemu typów powoduje, że łatwiej o potencjalnie
trudne do wykrycia błędy wynikające z nieprawidłowego użycia
interfejsów, o problemach z wydajnością nie wspominając. Przede
wszystkim jednak z tego, co napisałeś zgaduję, że to są rzeczy zupełnie
"po drugiej stronie Bluba" niż to, o czym pisałeś - jeszcze bardziej
"akademickie" i "przerost formy nad treścią" niż OO.

>> I owszem, jak ktoś
>> chce pracować jako programista, a nie umie porządnie stosować technik
>> obiketowych, to jest dla niego strata
>
> A może po prostu ci miłośnicy technik obiektowych nigdy nie nauczyli się
> porządnie stosować technik nie-obiektowych i to ich strata?

Oczywiście każda technika, której się porządnie nie nauczysz, to jakaś
tam strata. Tylko że właśnie wracając do punktu wyjścia, samodzielnie
klepiąc kod niczego się porządnie nie nauczysz.

>> i często też strata dla tych, co
>> mu dadzą pracę.
>
> Jeśli liczyli na to, że będzie pokornie programował obiektowo, to tak.
> Natomiast jeśli chcą aby efekty jego programowania były dobre - już
> niekoniecznie.

Wystarczy, że liczą, że "dobre efekty" zawierają w sobie również to, że
kod napisany przez tego osobnika będzie poprawnie korzystał z kodu
napisanego przez innych członków zespołu i że inni członkowie zespołu
(być może nie tacy geniusze jak ów osobnik) będą łatwo i nie generując
dodatkowych błędów wykorzystać ten kod. Również wiele lat po napisaniu
danego kodu i po rozlicznych modyfikacjach kodu wykorzystywanego,
korzystającego jak i częsci samego tego komponentu.