Когда и почему использовать методы доступа С#

Возможный дубликат:С# - Когда использовать свойства вместо функций

Я пытаюсь понять, когда и почему использовать "getters" и "seters"

кто-нибудь, пожалуйста, дайте некоторые рекомендации.

В чем разница между следующими конструкциями - посмотрите только на методы доступа.

//EXAMPLE 1: simple accessor method 
private static bool _isInitialEditMapPageLoad;
public static bool isInitialEditMapPageLoad
{
 get {return _isInitialEditMapPageLoad;}
 set {_isInitialEditMapPageLoad = value;}
}
//EXAMPLE 2: accessor method with a conditional test
private static bool _isInitialEditMapPageLoad;
public static bool isInitialEditMapPageLoad
{
 get 
 {
 if (currentSession[isAuthorizedUseder] == null)
 return false;
 else
 return _isInitialEditMapPageLoad; 
 }
 set {isInitialEditMapPageLoad = value;} 
}
//EXAMPLE 3: just a get accessor method - is this the same as EXAMPLE 4?
private static bool _isInitialEditMapPageLoad = false;
public static bool isInitialEditMapPageLoad
{
 get {return _isInitialEditMapPageLoad;}
}
//EXAMPLE 4: simple method
private static bool _isInitialEditMapPageLoad = false; 
public static bool isInitialEditMapPageLoad
{
 return _isInitialEditMapPageLoad; 
}
4 ответа

1: Это простое свойство и может использоваться во многом так же, как и в публичном поле. Если у вас есть причина, чтобы показывать операции get и set другим пользователям (то есть другим классам), и вам не нужно ничего интересного, вот и все. Это также можно записать с помощью "auto-properties",

public static bool isInitialEditMapPageLoad {get;set;} // behaves just like example 1

автоматические реквизиты намного быстрее записываются и, на мой взгляд, гораздо читабельнее, чем полная декларация (если я вижу полную декларацию с помощью поля поддержки, я ожидаю найти некоторую сложность).

2: Это показывает одну из причин свойств: использование некоторой логики для возврата значения, а не возврата значения напрямую. Кто-то может установить это значение, поскольку они будут публичным полем, когда захотят. Они могут получать значение, когда захотят, с оговоркой, что false означает, что это не начальная загрузка, или пользователь не авторизовался, то есть некоторая (простая) логика выполняется до возвращения значение.

3: Это ведет себя как общедоступное поле ТОЛЬКО для чтения - кто-то может получить значение, но не установить его. Это по существу значение, которое читается только внешнему коду (не путать с ключевым словом readonly)

4: Результат для компиляции для меня. Предполагая, что это должно быть объявление метода, вручную определяя геттер, как в Java, то он похож на пример 3. Я считаю, что есть другие проблемы, которые делают это не совсем так, например, если вы хотите повернуть это в свойство зависимостей и т.д. К сожалению, мои знания в этой области сокращаются.

==========

Как правило, свойства пользователя ограничивают доступ к вашим данным класса. Как принцип, все, что вы можете удержать, позволяя другому коду коснуться, должно быть сохранено таким образом. В практическом плане вы захотите установить значения в классах для изменения способа отображения, изменения представленных данных и т.д. Используйте свойства, чтобы поддерживать максимальный контроль над этим взаимодействием.

Если другим классам необходимо будет что-то просмотреть в своем классе, вам нужно будет открыть геттер, но не сеттер. Это невозможно с полями, если вы не используете метод Java для создания пользовательского метода getter. Они также позволяют выполнять вычисления или проверки перед возвратом или настройкой данных. Например, если у вас есть целое значение, которое должно быть в пределах некоторого диапазона (диапазон, который может меняться в зависимости от состояния вашего объекта, даже), в вашем setter вы можете проверить, чтобы убедиться, что это условие выполнено до фактического обновления ваше значение.

Попытайтесь избежать ловушки, просто устанавливая все как автопрограмму - это ничем не отличается от того, чтобы сделать все общедоступным. Держите все как можно более приватным. Без геттеров, если это не необходимо, нет сеттеров, если это необходимо, и сеттеры должны выполнять любую небольшую логику, необходимую для проверки ввода, прежде чем принимать его, если это необходимо. Тем не менее, избегайте другой ловушки: ставьте много кода в геттеры/сеттеры. Если требуется больше, чем несколько строк, вы должны скорее создать метод, а не свойство, просто потому, что он дает больший намек другим, используя ваш код, что произойдет что-то большое.


Ваши получатели/сеттеры должны быть вашим открытым интерфейсом для вашего класса.

Как правило, все ваши члены должны быть закрытыми, за исключением того, что вы хотите, чтобы люди имели доступ к вне вашего класса, и вы никогда не хотите, чтобы ваши частные переменные были доступны непосредственно снаружи, если ваш класс

Вот простой пример. скажем, у вас был класс, для которого вам нужна переменная age. В этом случае вы можете выполнить валидацию прямо в сеттере, если ваши внешние классы не должны знать, что это значение проверено.

class Person {
 int age = 0;
 public int Age {
 get { return age; }
 set { 
 //do validation
 if (valid) {
 age = value;
 }
 //Error conditions if you want them.
 }
 } 
 //More getters/setters
}


Обоснование Getters/Setters состоит в том, чтобы защитить класс от нарушения, когда пользователь изменяет поле недействительным способом, и они позволяют изменять реализацию вашего класса, оставляя неизмененные публично доступные свойства.

Если вам не нужны какие-либо проверки или ленивые свойства, вы обычно можете просто использовать автоматические свойства.

public string Name { get; set; }


Как и другие упоминаемые, используйте getters/seters, когда вы хотите, чтобы члены объекта были доступны другим объектам.

Кроме того, читаемость кода yoru может быть улучшена (если вы используете .NET 2.0 или выше), используя autoproperties. Ниже приведены примеры:

// example 1
public static bool IsInitialEditMapPageLoad { get; set; }
// example 3/4 - note that false is the default for bools
public static bool IsInitialEditMapPageLoad { get; private set; }

Пример 3, вероятно, останется прежним, из-за наличия логики проверки.

licensed under cc by-sa 3.0 with attribution.