On 04/13/2011 09:08 AM, Mariusz Marszałkowski wrote:
>> Techniki obiektowe to nei ejst "przerost formy nad trescia". Techniki
>> obiektowe stosuje sie tam gdzie ulatwiaja one pisanie programu. Nie
>> stusuje sie ich tam gdzie niczego nie wnosza.
>>
> Dobrze powiedziane. Z tym ze "cos" to chyba zawsze techniki
> obiektowe wnasza? Chocby szybsze odszukanie fragmentu kodu
> do poprawki po dlugiej przerwie?

Jeżeli program ma dobrą *strukturę*, to niekoniecznie. W większości
języków obiektowych też można napisać coś tak, że choćbyś miał zdechnąć,
to nie znajdziesz.

JD

do góry

On Wed, 13 Apr 2011 00:08:15 -0700 (PDT), Mariusz Marszałkowski
<m...@g...com> wrote:

>On 12 Kwi, 23:49, A.L. <l...@a...com> wrote:
>> On Mon, 11 Apr 2011 20:04:19 +0200, Wojciech Jaczewski
>>
>> <w...@o...pl> wrote:
>> >Andrzej Jarzabek wrote:
>>
>> >> Z drugiej strony też jest tak, że jak ktoś nie zna albo nie potrafi
>> >> stosować pewnych technik, to często uważa je za niepotrzebne (np. za
>> >> "przerost formy nad treścią", co uzadania tym, że sam potrafi się bez
>> >> nich obejść. I to też jest częsta przypadłość ludzi, którzy "uczyli się
>> >> sami".
>>
>> >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ć.
>>
>> Techniki obiektowe to nei ejst "przerost formy nad trescia". Techniki
>> obiektowe stosuje sie tam gdzie ulatwiaja one pisanie programu. Nie
>> stusuje sie ich tam gdzie niczego nie wnosza.
>>
>Dobrze powiedziane. Z tym ze "cos" to chyba zawsze techniki
>obiektowe wnasza? Chocby szybsze odszukanie fragmentu kodu
>do poprawki po dlugiej przerwie?
>Pozdrawiam
>

Niekoniecznie. Prosze sobie wyobrazic aplikacja ktora ma 2 tysiace
klas. Czy obiektowosc "ulatwia odnaleznienie kodu" raczej watpie.
Uklul sie termin "spaghetti objects". Przedtem tzrena zrozumiec te 2
tysiace klas - co one robie i jak ze soba wspolpracuja, zarowno
statycznie jak i dynamicznie.

Proponuje sie zastanowic skad sie wzial model obiektowy: wzial sie w
jezyku Simula 67 ktory byl (mimo ze uniwersalny) przede wszystkm
przeznaczony do SYMULACJI, a wiec strukturalnego odwzorowania
rzecywiscosci w postaci programistycznych obiektow, oraz z metodologii
"frames" w AI, gdzie motywacja byla podobna. I dzisiaj model
obiektowy sprawdza sie doskonale gdy tzreba miec w komputerze
odwzorowana sytuacje rzeczywiscta, a wiec wszelkiego rodzalu
modelowaniu procesow, optymalizacji itede.

Tym niemniej sa sytuacje gdy model obiektowy poasuje jak przyslowiowy
"garbaty do sciany" - znajomy czlowiek stracil duzo czasu usilujac
"obiektowo" napisac biblioteke do analizy sygnalow przy pomocy
"wavelets" ("falek" po naszemu), skonczylo sie to wielkim wyrzucaniem
do smeici i powrotem do czystego C. Nawet nie C++.

Podwumowujac, obiektowosc to nie "silver bullet" ani kamien
filozoficzny ale jedno z narzedzi w "toolboksie". Tzreba go uzywac
wteny gdy sie nadaje, a nie uzywac jak sie nie nadaje. Podobnie jak
budowniczy wie kiedy uzyc wietrarki a kiedy mlotka. Wiertarka, mimo ze
bardziej elegancka niz mlotek, slabo nadaje sie do wbijania gwozdzi.

A.L.

do góry

W dniu 2011-04-13 16:01, Jędrzej Dudkiewicz pisze:
> On 04/13/2011 08:46 AM, wloochacz wrote:
>> W dniu 2011-04-12 21:17, Wojciech Jaczewski pisze:
>>> 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...
>
> Bez przesady, wracasz do starego wątku "czy pisać wszystko w C++/Javie,
> czy może jednak użyć narzędzia specjalizowanego, czyt. Prolog".
Nie, nie wracam.
Z jednym się zgodzę - teza przedstawiona jako aksjomat, że OOP pomaga
(is the best) lub przeszkadza (is the worst) w każdym
programie/zastosowaniu/whatever jest idiotyczna.

Tknęło mnie dokładnie to zdanie, które zacytowałem - wynika z niego,
jakoby Wasza aplikacja była zbiorem programów (w sensie osobnych
procesów, tak jak rozumie to OS).
Nie wyobrażam sobie czegoś takiego na *moim* podwórku, tyle że ja jestem
prosty wyrobnik od aplikacji bazodanowych.
Powiedzmy.

--
wloochacz

do góry

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

do góry

Andrzej Jarzabek wrote:

>> Sprecyzuję, co ja rozumiem pod pojęciem "przerost formy nad treścią".
>> Program napisany na wyczucie, bez zastosowania różnych "dobrych praktyk"
>> można zapisać w X linii kodu. Ktoś jednak upiera się by zrobić to np.
>> "obiektowo" i wychodzi mu 3*X linii. W takim kodzie nie widać, co się
>> rzeczywiście dzieje, bo jego duża część to bezużyteczne wypełniacze.
>
> Taki jest właśnie problem z samodzielnymi klepaczami: nie wiedzą gdzie
> należy czego używać, nie mają pojęcia na temat dobrych praktyk więc
> wymyślają na ich temat jakieś mity, nie potrafią czytać kodu, a
> wszystko, czego sami nie potrafią sensownie użyć jawi im się
> "bezsensownym wypełniaczem".

Taka dość znana postać jak Linus Torvalds pewnie też jest samodzielnym
klepaczem, bo też da się znaleźć jego negatywne opinie na temat m.in.
programowania obiektowego.
Zdecydowanie chciałbym kiedyś osiągnąć taki poziom jak L.T. a nie jak 99%
"profesjonalistów", mających pojęcie o "dobrych praktykach".

do góry

On Wed, 13 Apr 2011 21:09:31 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

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


Niby dlaczego?... U mnie w firmie zawsze jest wiecej do srobienai niz
"mocy przerobowych" co nie przeszkadza miec rozne dokumenty pod
wspolna nazwa "programming standards" ktorych przestzreganie jest
wymuszane w sposob drakonski, poczawszy od zautomatyzoanych narzedzi
po manualne "code reviews". Dzieje sie tak, albowiem zauwazono (nie
tylko w mojej firmie) ze "strata czasu" zwiazana z porzadnym
kodowaniem jest znacznie mniejsza nis rzeczywista strata czasu
znacznie pozniej, gdy przyjdzie modyfikowac program lub szukac bledow.

A.L.

do góry

On Wed, 13 Apr 2011 21:13:52 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>Andrzej Jarzabek wrote:
>
>>> Sprecyzuję, co ja rozumiem pod pojęciem "przerost formy nad treścią".
>>> Program napisany na wyczucie, bez zastosowania różnych "dobrych praktyk"
>>> można zapisać w X linii kodu. Ktoś jednak upiera się by zrobić to np.
>>> "obiektowo" i wychodzi mu 3*X linii. W takim kodzie nie widać, co się
>>> rzeczywiście dzieje, bo jego duża część to bezużyteczne wypełniacze.
>>
>> Taki jest właśnie problem z samodzielnymi klepaczami: nie wiedzą gdzie
>> należy czego używać, nie mają pojęcia na temat dobrych praktyk więc
>> wymyślają na ich temat jakieś mity, nie potrafią czytać kodu, a
>> wszystko, czego sami nie potrafią sensownie użyć jawi im się
>> "bezsensownym wypełniaczem".
>
>Taka dość znana postać jak Linus Torvalds pewnie też jest samodzielnym
>klepaczem, bo też da się znaleźć jego negatywne opinie na temat m.in.
>programowania obiektowego.
>Zdecydowanie chciałbym kiedyś osiągnąć taki poziom jak L.T. a nie jak 99%
>"profesjonalistów", mających pojęcie o "dobrych praktykach".

Z faktu ze L.T. napisal (sciagnal?...) kernel Linuxa nei wynika
zupelnie ze a) jest znakomitym programista, b) ma podstawy do
jakichkolwiek uogolnien, zwlaszcza w dziedzinie na ktorej sie nie zna
("uwazam ze programowanei obiektoew ejst do dupy, czego najlepszym
dowodem jest to ze nigdy go nie uzywalem")

A.L.

do góry

Andrzej Jarzabek wrote:

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

Ale tu wcale nie tworzy się barier, aby drugi człowiek korzystał z
fragmentów pierwszego. Pasuje mu, to korzysta, nie - to nie.

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

Chciałem. Opamiętanie się, zajęło mi około dwa lata (pracy zarobkowej +
własnych eksperymentów).
Niestety nasza dyskusja skazana jest na bycie nieco jałową, bo przecież nie
wrzucę na grupę dyskusyjną programów wykonywanych w pracy, aby inni mieli
szansę zrobić obiektowy kontr-przykład do porównania czytelności tych dwóch
wersji.

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

Stosowanie rozwiązań modnych ma swoje zalety, ale czasem warto modę
odrzucić.

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

Są w internecie kody źródłowe projektów, które się udały i utrzymały się
przez wiele lat. Można oglądać i próbować naśladować.

do góry

A. L. wrote:

> Z faktu ze L.T. napisal (sciagnal?...) kernel Linuxa nei wynika
> zupelnie ze a) jest znakomitym programista,

To po czym się rozpoznaje dobrego programistę? Po tym, że dobrze recytuje
książki?

do góry

> >> Sprecyzuję, co ja rozumiem pod pojęciem "przerost formy nad treścią".
> >> Program napisany na wyczucie, bez zastosowania różnych "dobrych praktyk"
> >> można zapisać w X linii kodu. Ktoś jednak upiera się by zrobić to np.
> >> "obiektowo" i wychodzi mu 3*X linii. W takim kodzie nie widać, co się
> >> rzeczywiście dzieje, bo jego duża część to bezużyteczne wypełniacze.
> >

dla mnie w tej calej kwesti mozna wyroznic dwa duze tematy

1) ew kwestia czy owo omawiane oo jest coskolwiek warte - to jest
pytanie tzw normalne - techniczne

2) zadziwiajaca kwestia czemu to oo tak sie upowszechnilo i czemu
przyciaga tak wiele osob - to z kolei ten temat jest dla mnie zgola
nienormalne i jest to pytanie raczej socjologiczne -- nie mam pojecia
ew moglbym probowac odpowiedzi typu "byc moze glupolom brdziej imponuje
to co jest mgliste bo to czego nikt w spolecznosci nie rozumie wydaje
im sie 'wieksze'" - acz jest to tez watpliwe i nie umiem odpowiedziec
- jest to w kazdym razie swojego rodzaju socjologiczny fenomen tajemnica


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry