On Fri, 17 Feb 2012 17:40:07 +0000, Bronek Kozicki <b...@s...net>
wrote:

>On 17/02/2012 16:36, A.L. wrote:
>> On Fri, 17 Feb 2012 13:58:07 +0100, szyk<s...@o...pl> wrote:
>>
>>> * zasady OOP (Obiektowo Orientowane Projektowanie) - ściąga z tych
>>> zasad: brak duplikacji kodu, enkapsulacja, operowanie na interfejsach
>>> zamiast na implementacji, preferowanie kompozycji zamiast dziedziczenia,
>>> atomowa odpowiedzialność klas, klasy otwarte na rozbudowę ale zamknięte
>>> na modyfikacje, sensowne dziedziczenie
>>
>> Tak na marginesie, polecam ksiazke
>>
>> Skunk Works: A Personal Memoir of My Years of Lockheed
>> Ben R. Rich, Leo Janos
>>
>> To tak ogolnie na pemat projektowania.
>>
>> A tak powaznie, to model Kolegi pachnie mi "waterfall model". Tak sie
>> od dawna nie robi. Programy sie raczej pisze iteracyjnie. Trudno od
>
>zastanawiam skąd to się bierze, u początkujących (moje wrażenie sądząc
>po początu wątku), w 21 wieku. Nauka ze starych podręczników? Procedura
>do własnych studenckich projektów?
>

Moze chec do uporzadkowanai wszystkiego? Zeby bylo klarowne, jasne i
zdeterminowane?

"Waterfall methodology" nie jest zreszta cakiem bezuzyteczna. Sprawdza
sie doskonale przy budowie domow i mostow, na przyklad. Ale software
ma nieco inna nature...

A.L.

P.S. Tak na marginesie, tam jest pare innych rzeczy: wiara w moc
wzorcow projektowych, wiara w To Co Powiedzial Guru (cytat:
"operowanie na interfejsach zamiast na implementacji" i dalej)
niezaleznei od tego czy Guly ma tak zwane "clue" czy nie.

Niedawno mialem ostra dyskusje z "mlodym miszczsem" na temat
implementacji hashCode() w Javie. Miszcz upieral sie ze jego
implementacja jest jedynie sluszna. Argument: "Bo skopiowalem to z
ksiazki Effectiva Java, a jak tam jest napisane to znaczy ze tak
tzreba robic". Z dalszej dyskusji wyniklo ze jezeli sie robi inaczej
niz w tej ksiazce, to na pewno robi sie zle. O tym ze w konkretnym
przypadku ta implementacja ma sensu, nei dalo sie miszcza przekonac.