get/ set method vs public variable

Като Джавар съм за.

От Сън ги препоръчват и казват, че компилатора на Джава е оптимизиран да не прави разлика между set/get и директен достъп до полето. Демек, няма голямо забавяне, ако ползваш set/get. Също така, доста спецификации на Джавата като JavaBeans и пр., се въртят около set/get и са направо задължителни.

Освен това се постига пълна капсулация - нещо много важно. Голяма част от хората ги ползват по интерция, щото така било модерно или щото шефа искал така. И пропускат основната идея да има проверка на входните данни при set. Аз си слагам там проверките на параметрите и хвърлям IllegalArgumentException, ако параметър не отговаря на условията. До сега не съм видял друг да слага там някакви проверки. Така, че в този случай set не е празен. А това е класически случай за капсулиране, даже се преподава по ООП. Ако трябва да се установи някакъв член на някакъв обект и той трябва да отговаря на някакви условия, примерно да е по-голям от нула, и данните се въвеждат от потребителя. Мястото на проверката е твърдо там.


Има някои случаи, когато могат да не се ползват. Но за този случай повечето езици имат Struct. Май Джавата е единствената дето няма. В този случай може да си направиш един клас с публични членове и да си ги викаш както ти кефне. Но в другите езици е по-добре да използваш Struct - това е същото като клас, само дето няма методи има само членове.

Ми много често get/set си е класически случай на лоша капсулация/дизайн!
Правейки клас, ти предлагаш определена функционалност върху множество от зависещи помежду си данни (ако не зависят - защо са в един клас!?). Да позволяваш get/set извън контекста на работа на класа - това значи да го излагаш на риск - че някой отвън може съвсем легално да промени интегритета на капсулираните данни.

Хайде и аз да се изцепя :)

Твърдо съм за get/set. Ще се опитам да се аргументирам.

1. Понякога искаме да дадем само readonly достъп до някое поле на класа. Публично поле дава и двете... Иначе дефинираме само get.
2. Добра практика е мисля, да се проверява за валидни стойности при set-ване на дадено поле. Няма как да стане с публично поле. При set си проверяваме за валидни стойности.

Общо взето с get/set имаме по-голям контрол върху състоянието на обекта и не може някой да го счупи като зададе неподходяща стойност на някое публично поле.

Добре. Пример обект превозно средство - има ен на брой колела - трябва ми да знам колко колела има, но не и да променям броя им. Как става според теб?
Без get?

с const ;)

Aaaa, тука нещо не ми става ясно за какво говориш...какъв get/set извън конктекста на класа, какви 5 лева, какъв риск...точно обратното е, кат си дадеш public member могат да ти набучат каквото си искат вътре, със set-ер винаги можеш да си валидираш, обновиш dependacies etcetcetc

Eee, нали затова казах че е превозно средство (базов клас) :) Има коли, мотоциклети, триколки :)

Това, което казвам, е че ударението пада обикновено върху дизайна, а не върху - get/set или public данни.
Ако видиш дизайн, декориран с много get/set, може би нещо му куца - най-вероятно.
-----------
Класа обикновено контролира множество от данни, които променя интегрирано с методите си. Да сложиш "set" извън главната му функционалност, независимо от проверките в "set", означава да промениш нещо и само едно, оставяйки останалите данни несинхронизирани с промяната.
Нали обикновено целиш промяна в състоянието на обектите от класа, което далеч не е смяна на едно нещо.
Най-вероятно при наличие на get/set по-скоро имаш нужда от struct тип.

<quote>
Класа обикновено контролира множество от данни, които променя интегрирано с методите си. Да сложиш "set" извън главната му функционалност, независимо от проверките в "set", означава да промениш нещо и само едно, оставяйки останалите данни несинхронизирани с промяната.
Нали обикновено целиш промяна в състоянието на обектите от класа, което далеч не е смяна на едно нещо.
Най-вероятно при наличие на get/set по-скоро имаш нужда от struct тип.
</quote>

wtf ?

"Hide Your Data and Make Objects Responsible for their Own User Interfaces"
Потърси това в MSDN-a или в интернета. Има интересни работи по въпроса.

Set-а е обикновенно част от главната функционалност, едва ли можеш ей така да си сложиш set само за да set-ваш нещо си без това да се отрази на обекта. Както писах и по-нагоре, със setter можеш транспарентно (от user-a) да промениш целия state на обекта, а не едно пропърти.

Очевидно, че ако целия ми обект има само get/set върху несвързани данни (калкулируеми полета като прост пример) и никаква друга функционалност, то няма да имам class, а POD тип.

Имам чувството, че не си разбрал темата.

Най-вероятно, за теб set се изразява само да установи даден член без да извършва проверка на параметъра. В интерес на истината над 90% от случаите хората го употребяват за това и наистина е дразнещо.

Моля, те прочети още веднъж какво сме писали повечето по темата, поне под моето разклонение.

Е аре сега, ще наследяваш заради едни колела ;)

Не е хубаво така, да не говорим, че не е и модерно - правиш броя на колелата темплейтен параметър и си готов...или ъмм нещо от тоя тип ;)

повечето давате примери главно за сет.
според мен и гет си има предимства - т.нар. lazy initialization
не зареждаш нещо докато на някой не му потрябва. за това гет е идеален.
освен това има aggregation и др. екстри

10000000000 % get/set, osobeno ako pishesh kod kojto she se plzva ot drugi!

По-лесна подръжка - оверхеад е малак.
Абсолютно се дефинира поведението при гет /сет, лесно се променя, ъпгрейдва/ подържа. Лесно се имплементират допълнителни фййчърс - нотификации, валидации. Лесно се протектва от Хийп/Фрейм оверрън!

Какво повече????

хм за тва вобще не се бех сетил
имало полза и от тоя форум

> Ако видиш дизайн, декориран с много get/set, може би нещо му куца - най-
> вероятно.
Sic!

Най-после някой, който разбира от дизайн.

Можем да заформим един флейм темплейти срещу наследяване :) Сигурно ще има интерес

Май в повечето случаи тези стандарти са от вида "слагайте си отварящите скоби на същия/нов ред", "използвайте Camel/Pascal casing за методите". Главно козметични работи :)

В отговор на:

---

как културно да проверя от тест някой private member на клас дето тествам?

---

Конкретен пример? За мен въпроса е странен, защото сигурно има 100 кила неща дето мога да направя, за да не стигам до такива скачания през запалени обръчи.

--
Екстремно програмиране на български.
[линк]