On 17/04/2011 20:34, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> Przy czym dla podejścia strukturalnego/proceduralnego z punktu widzenia
>> inżynierskiego takie sytuacje w zasadzie wyczerpuje scenariusz "program
>> ma mniej niż 20 linii kodu";
>
> Zachowaj choć trochę realizmu. Nawet programy do wykonywania pojedynczych
> czynności, jak np. te zebrane w "util-linux" trochę linii jednak mają. Chyba
> że uważasz, że nawet to autorzy koniecznie powinni to przepisać w stylu
> bardziej OO, dzięki czemu wszyscy użytkownicy zyskają...

Mówiłem przy podejmowaniu decyzji przy pisaniu nowego programu. W
przypadku legacy sytuacja jest zupełnie inna: po pierwsze masz gotowy
program, który działa, błędy w nim były eliminowane przez ileś lat i
jakby go pisać od nowa, to trzebaby ponieść jakieśtam koszta i poświęcić
czas tylko po to, żeby doprowadzić go do stanu, w którym teraz już go
masz. Druga zespół, który pisał program, zna funkcjonalność, dziedzinę
itd., a niekoniecznie zna OO czy jakieś tam inne techniki, które by było
sensownie zastosować. To jest historia stara jak świat.

Oczywiście te 20 linii nie trzeba koniecznie traktować dosłownie sam
napisałem niedawno skrypt w Perlu który miał pewnie ze 200 linii i nie
było w nim sensu stosować OO.

>> Ktoś, kto myśli, że obiektowość - w stosunku do programowania
>> strukturalnego - zaciemnia intencje, utrudnia modyfikacje programu,
>> spowalnia początkowy development, że to przerost formy nad treścią i
>> różne inne "mądrości" wyrażone w tym temacie w tym wątku, nie tylko
>> nigdy nikogo nie przekona w żadnej sensownej firmie stosującej OO
>
> Tego, że w firmie, która uparła się na OO nie przekonam do jej porzucenia,
> to zdaję sobie sprawę. Będę wybierał takie, gdzie OO nie jest obowiązkowe.
>
> Gdy różnica w poglądach między jedną a drugą osobą w dyskusji jest zbyt
> drastyczna, o przekonaniu którejś ze stron nie może być mowy.

Nie wypowiadam się akurat o twoim przypadku, bo nie znam konkretów i
może jesteś wyjątkiem, ale w abstrakcyjnym przypadku kogoś, kto może się
czegoś nauczyć lub nie nauczyć żeby pracować jako programista, jest taki
problem:
1. Ktoś nie znający dobrych praktyk inżynierii oprogramowania w ogóle, a
OO w szczególności ma na dzień dobry bardzo ograniczony wybór tego,
gdzie go będą chcieli przyjąć do pracy.
2. Jeśli zatrudni się w firmie nie stosującej dobrych praktyk, to ta
firma będzie miała niskie przychody, więc raczej może liczyć na słabe
zarobki i/lub warunki pracy.
3. Firma ta w końcu zapewne zbankrutuje, a nasz programista straci pracę.
4. W końcu szukając kolejnej pracy rozbije się o problem, że firma miała
złą reputację z powodu niskiej jakości swoich produktów, i lata
przepracowane w tej firmie i wpisane w CV nie będą działać tak bardzo na
korzyść naszego programisty.

To są oczywiście ogólne prawidłowości, od których naturalnie są wyjątki,
ale lepiej mieć lepsze szanse, niż gorsze, nie?