wloochacz wrote:

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

Tak się dzieje, gdy jest mało ludzi, a wiele do zrobienia. Można by
prowadzić zbiorowe rozważania i zmuszać jednych do stosowania formy innych,
ale wtedy trzeba byłoby zrezygnować z większości zamówień.

> Tylko, że to wina szefa projektu - a raczej jego brak...

Narzucanie zbyt wielu rzeczy przez szefa projektu kończyłoby się tym, że
żaden wykonawca nie czułby się osobiście odpowiedzialny za powodzenie
projektu i starałby się tylko literalnie wykonywać polecenia, bez
zastanowienia się czy to ma sens - w razie czego wiadomo, kto jest winny:
kierownik.

>> 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?

Staram się stosować wzorce projektowe: te pochodzące z Uniksa - zdecydowanie
nie-obiektowe.
Te często wspominane, opisane w jakiejś tam książce czterech autorów, są dla
mnie w większości nieprzydatne.

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

Zwyczajnie. Doucza się i programuje zgodnie z panującą w danej firmie modą
(zakładając, że bardziej mu zależy na programowaniu akurat w tej firmie, a
nie programowaniu w sposób, który uważa za właściwy).