🚀 go-pugleaf

Jaroslaw Kowalski wrote:
>> Co jest w tym nieobiektowego? Przepraszam bardzo ale takiej
>> definicji obiektowości nie znam.
> 
> Jedną z podstawowych cech obiektowości jest (wybierz właściwe słowo):
> 
> 
> 1. encapsulation 2. hermetyzacja 3. enkapsulacja 4. kapsułkowanie
> (pozdrowienia dla p. JMD) 5. ... 6. ... 7. ...
> 
> Udostępnienie publicznego pola, po którym każdy z zewnątrz może pisać
> bez kontroli jest zaprzeczeniem tej idei.

Idei _pełnej_enkapsulacji_, tak.
Z Wikipedii:
"Z pełną enkapsulacją mamy do czynienia wtedy gdy dostęp do wszystkich
pól w klasie jest możliwy tylko i wyłącznie poprzez metody, lub inaczej:
gdy wszystkie pola w klasie znajdują się w sekcji prywatnej (lub
chronionej)."

Zgadzam się, że w większości przypadków da się tego paradygmatu
trzymać, ale w szczególnych przypadkach lepiej jest go pominąć
i nie wpłynie to na zachowanie obiektowości w kodzie.

>>> Wystarczyło zabronić ich stosowania i w każdym przypadku
>>> generować automatycznie właściwość z ukrytym polem prywatnym
>>> przechowującym stan.
>> 
>> No, to byłby naprawdę wynalazek na miarę "systemu totalitarnego 
>> programowania". Czy naprawdę tak ciężko jest samemu napisać kod
>> właściwości? Dlaczego odbierać komuś możliwość korzystania z pól
>> publicznych?
> 
> 
> Ależ skąd. Chodzi raczej o generowanie automatyczne właściwości 
> opakowujących te pola. W .NET masz rozróżnienie na pola i
> właściwości, gdzie raczej jest zgoda że w publicznych interfejsach
> należy używać właściwości. Gdyby wszystkie pola publiczne były przez
> kompilator tłumaczone jako właściwości (Property) a nie pola (Field)
> to zniknąłby problem kompatybilności binarnej.

W interfejsach (nie klasach) jak najbardziej, ponieważ tu faktycznie
upublicznianie pól jest b.kontrowersyją sprawą. Ale jeśli ktoś trzyma
się dobrego stylu OOP to nie utworzy interfejsu z polami. A napisanie:
int MyInt {get;set;}
naprawdę zajmuje tylko 10 znaków więcej.

>>> JITter dość dobrze radzi sobie z inline'owaniem takich
>>> konstrukcji jak trywialne get/set więc chyba nie powinno być
>>> problemu wydajnościowego. Zachowana zostałaby za to binarna
>>> kompatybilność kodu w przypadku zdefiniowania własnej operacji
>>> get/set w przyszłości.
>> 
>> Oczywiście wszystko da się zrobić. Ale jak to się ma do 
>> przejrzystości kodu i składni samego języka?
> 
> Mówię tylko o tym, że dla uniknięcia Field'ów w interfejsie
> publicznym kompilator mógłby tłumaczyć:
> 
> -------- public int Counter; --------
> 
> każdorazowo na
> 
> -------- private int _Counter; public int Counter { get { return
> _Counter; } set { _Counter = value; } } --------
> 
> public readonly typ nazwa; byłoby tłumaczone jako właściwość z
> akcesorem(?) get a pola prywatne zostałyby po staremu.

I tu się z Tobą nie zgadzam.
Podejrzewam, że dobre narzędzia UML wygenerowałyby taki
właśnie kod. Takie rzeczy powinny być załatwiane na poziomie
wspomagania pisania kodu, a nie na poziomie kompilatora.
Jeśli "ja" chcę mieć _pole_publiczne_ w klasie to chcę mieć
_pole_ , a nie własność. Jeśli chciałbym stworzyć prostą
klasę, z szybszym dostępem do wartości pól, to kompilator
mi na to nie pozwolił, bo stworzyłby właściwość, która
tak naprawdę jest 2 metodami. A "ja" nie chcę, żeby
kompilator przewidywał co ja od niego wymagam, ale chcę,
żeby kompilator robił to co "ja" mu każę.

>> Osobiście jestem przeciwnikiem tego co M$ zrobił ze składnią 
>> właściwości o różnych modyfikatorach dostępu, czyli:
>> 
>> public int IntValue { get { // ... } protected set { // ... } }
> 
> 
> A ja jestem za. W Soodzie bardzo chętnie bym powitał takie
> usprawnienie już w .NET 1.1. Chodzi głównie o możliwość ustawienia
> "set" jako "internal". Czyli biblioteka/assembly/pakiet kodu sama
> może zmodyfikować jakąś właściwość a klienci mogą tylko ją czytać.
> Obecnie muszę robić SetXXX() do ustawiania i int XXX { get; } do
> pobierania.

Ja także jestem ZA taką funkcjonalnością, ale jestem
przeciwko składni:
public int IntValue {
	get {...} //
	protected set {} //
}

Wolałbym coś takiego:

public int IntValue {
	get {...}
}
protected int IntValue {
	set  {...}
}

Za długie? No, może 2 linie więcej, ale osobiście wydaje mi
się, że dużo b.czytelniejsze. Od razu widać co jest publiczne
a co chronione. Nie muszę pamiętać, że dając protected przy
_get_ mogę dać private... (albo także internal) przy _set_.
Przecież własności to są zwykłe metody dlatego nie rozumiem
dlaczego M$ nie pozwolił na ich rozdzielenie.
Ale to takie moje prywatne żale.

pozdrawiam
Marcin