Какво трябва и какво не трябва да правят Getters и Setters

Моето виждане:

1. Ако сетер или гетер се очаква да бъде скъп, не го превръщайте в свойство, направете го метод.

2. Ако настройката на свойство задейства събития поради промени, това е добре. Как иначе бихте позволили на слушателите да бъдат уведомявани за промени? Въпреки това може да искате да предложите двойка BeginInit/EndInit за потискане на събития, докато не бъдат направени всички промени. Обикновено отговорността на манипулатора на събитието е да се върне незабавно, но ако наистина не можете да му се доверите, че ще го направи, тогава може да поискате да сигнализирате събитието в друга нишка.

3. Ако настройката на свойство хвърля изключения за невалидни стойности, това също е добре. Това е разумен начин да сигнализирате за проблема, когато стойността е напълно грешна. В други случаи задавате куп свойства и след това извиквате метод, който ги използва, за да направи нещо, като например създаване на връзка. Това би позволило задържане на валидиране и обработка на грешки, докато свойствата не бъдат използвани, така че свойствата няма да трябва да хвърлят нищо.

4. Достъпът до собственост може да има странични ефекти, стига да не са неочаквани и да нямат значение. Това означава, че JIT екземпляр в getter е добре. По същия начин, задаването на мръсен флаг за екземпляра, когато се прави промяна, е съвсем добре, тъй като задава свързано свойство, като например различен формат за същата стойност.

5. Ако прави нещо вместо просто достъп до стойност, това трябва да е метод. Методите са глаголи, така че създаването на връзка ще се извърши от метода OpenConnection(), а не от свойство Connection. Свойство Connection ще се използва за извличане на използваната връзка или за свързване на екземпляра към друга връзка.

редактиране - добавено 5, променено 2 и 3

Съгласен съм с идеята, че getters/settings не трябва да имат странични ефекти, но бих казал, че те не трябва да имат неочевидни странични ефекти.

Що се отнася до хвърлянето на изключения, ако задавате свойство на невалидна стойност (в много основен смисъл), тогава изключенията за валидиране са добре. Въпреки това, ако сетерът изпълнява цяла поредица от сложни валидации на бизнес правила или се опитва да излезе и актуализира други обекти или каквото и да е друго нещо, което може да причини изключение, тогава това е лошо. Но този проблем всъщност не е проблем със самото изключение, а по-скоро, че сетерът се изключва и тайно изпълнява много функции, които повикващият не би (или не трябва) да очаква.

Същото и със събитията. Ако сетер хвърля събитие, което казва, че "това свойство се е променило", тогава е ОК, защото това е очевиден страничен ефект. Но ако задейства някакво друго персонализирано събитие, така че да накара някаква скрита част от кода да се изпълни в друга част на системата, това е лошо.

Това е същата причина, поради която избягвам мързеливото зареждане в гетъри. Наистина, те могат да направят нещата по-лесни през много време, но могат да направят нещата по-объркващи през някои от времето, защото винаги има сложна логика около това кога точно искате дъщерните обекти да бъдат заредени. Обикновено това е само още един ред код за изрично зареждане на дъщерните обекти, когато попълвате родителския обект, и това може да избегне много объркване относно състоянието на обекта. Но този аспект може да стане много субективен и до голяма степен зависи от ситуацията.

Винаги съм намирал консервативния подход за най-добър, когато работя в C#. Тъй като свойствата са синтактично същите като полетата, те трябва да работят като полета: без изключения, без валидиране, без забавна работа. (Наистина, повечето от моите свойства започват като прости полета и не се превръщат в свойства, докато не е абсолютно необходимо.) Идеята е, че ако видите нещо, което изглежда като получаване или настройка на набор от полета, тогава това Е нещо като получаване или настройка на поле, по отношение на функционалност (няма хвърлено изключение), цялостна ефективност (настройването на променливи не задейства каскада от делегирани повиквания, например) и ефект върху състоянието на програмата (настройването на променлива задава тази променлива и не не призовавам много делегати, които биха могли да направят почти всичко).

Разумните неща за набор от свойства включват задаване на флаг, който да показва, че е имало промяна:

set {
    if(this.value!=value) {
        this.changed=true;
        this.value=value;
    }
}

Може би действително задайте стойност на друг обект, напр.:

set { this.otherObject.value=value; }

Може би разглобете входа малко, за да опростите вътрешния код на класа:

set {
    this.isValid=(value&Flags.IsValid)!=0;
    this.setting=value&Flags.SettingMask;
}

(Разбира се, в последните два случая функцията get може да направи обратното.)

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