W dniu 2011-04-12 21:17, Wojciech Jaczewski pisze:
> Andrzej Jarzabek wrote:
>
>>> Dzięki temu, że uczyłem się sam, zdołałem się wydostać z pułapki
>>> stosowania właśnie takiego przerostu formy nad treścią. Bo gdy zacząłem
>>> stosować m.in. techniki "obiektowe", miałem możliwość porównania efektów
>>> z tym, co robiłem zanim zacząłem je stosować. Początkowo wydawało mi się,
>>> że to tylko przejściowe trudności (że skoro wszyscy to propagują, to
>>> pewnie coś w tym jest), ale po jakichś dwóch latach dotarło do mnie, że
>>> rzeczywiście zmieniłem technikę na gorszą i trzeba się z tego wycofać.
>>
>> 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. A da się też robić dobre programy bez nich.
> 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). 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.
Dla mnie brzmi to jak horror i dokładna definicja samowolki.
Potem przychodzi na miejsce jednego artysty drugi artysta i robi
poprawki. Tak jak mu pasuje.
REWELACJA.
Tylko, że to wina szefa projektu - a raczej jego brak...

>> 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ć.
Yhm.
Słyszałeś o wzorcach projektowych i umiesz je stosować w praktyce?

> Tworząc jakieś hierarchie obiektów,
> ciągle natrafia się na coś, czego się nie przewidziało i trzeba prawie
> całkowicie przebudowywać program.
Wiesz, jak zaimplementujesz program jako hierarchię obiektów-bogów - to
fakt - będzie to wyglądało jak opisujesz.
Tylko, że to nie ma nic wspólnego z OOP - nic a nic.

>> 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?
A przez porządnie rozumiesz "[...]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"?
Litości...

>> 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.
Jasne.
Jak sobie wyobrażasz spełnienie wymogu programowania obiektowego przez
programistę, który co najwyżej umie używać obiektów.
W ten sposób ów człowiek się męczy a fimra dostaje potworek...

--
wloochacz