🚀 go-pugleaf

W wiadomości: 10eh9tp6f64pb.dlg@fdsvzxcc.rtb.com,
Tomasz Kopacz <tkopacz@nospam.idg.com.pl> napisał(a):
> On Wed, 02 Nov 2005 15:55:37 +0100, Marcin Grzębski wrote:
>
>> Jeśli "ja" chcę mieć _pole_publiczne_ w klasie to chcę mieć
>> _pole_ , a nie własność.
>
> A możesz napisać dlaczego chcesz pole a nie własność? Bo "szybsze", bo
> mniej pisania?

Witam!

Nie zawsze musi być publiczne, może być także protected albo internal. 
Dobrze mieć wybór.

Poza tym jak słusznie zauważyłeś może być to też problem wydajność 
(programu). Jeśli taki polem będzie struktura można sobie zaoszczędzić 
kopiowania danych. Ponadto takie rozwiązanie umożliwia przekazanie pola jako 
argumentu typu ref i out.

Także w pewnych sytuacjach dobrze jest mieć wybór. Czy to w przypadku 
dziedziczenia, czy to w przypadku prostszych formularzy gdzie czasem można 
sobie pozwolić na takie uproszczone rozwiązanie jak samo pole. I w dodatku 
oznacza to mniej kodu.

Pole publiczne nie jest takie złe jak by się to mogło wydać. W ogromnej 
ilość przypadków nie ma potrzeby zmieniać wewnętrznej implementacji 
przechowywanych danych. Platforma .Net i kompilator za nas to załatwia 
dostarczając zestaw standardowych typów danych. Zatem te typy zapewniają już 
częściową hermetyzację -- ukrywają binarne szczegóły implementacji. Tracimy 
tylko kontrolę na tym, kiedy pole jest modyfikowane. Moim zdaniem są 
przypadki stosunkowo prostego kodu tworzonego w dużej ilości, w którego 
przypadku takie uproszczenie jest nawet pożądane. Co innego tworzenie 
wielokrotnie wykorzystywanych bibliotek -- wewnętrznego API projektów. Tu 
należy być bardziej rygorystycznym.

W czasie dyskusji padł także argument GOTO. Sprawa jest opisana przez 
Donalda Knutha i zostało pokazane, że w pewnych sytuacjach zagnieżdżonych 
pętli GOTO upraszcza kod i czyni go bardziej czytelnym (O ile dobrze 
pamiętam źródło i argumenty). W C# GOTO zwykle jawnie się nie wykorzystuje, 
ale jest return, break i jeszcze inne instrukcje skoku. Jeśli nasz kod nie 
ma jednego wejścia i wyjścia to nie jest już w pełni strukturalny. Zatem pod 
tym względem retrun powinno się znajdować tylko na końcu metody.

Warto te zasady znać aby tworzyć przejrzysty kod, który otworzony po kilku 
latach da się czytać. Ale przestrzeganie tych zasad tak wprost i bez 
refleksji moim zdanie także nie jest dobrym rozwiązaniem. Ponadto czasem 
niektóre zasady czy reguły mogą być dyskusyjne. Takie wrażenie odnoszę 
zwłaszcza w stosunku do inżynierii oprogramowania. Stosowane systemy są 
skomplikowane, nauka i wykorzystanie ich jest czasochłonna. A zyski z 
używania mocno dyskusyjne.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_marek(małpa)gazeta(kropka)pl ]
[ == USUN_TO. z adresu == ]