Использует получают установленные свойства C#, который рассматривают хорошей практикой?

Нет, Вы входите в область Контекстно-свободные грамматики в той точке.

10
задан Joel Coehoorn 9 December 2011 в 14:48
поделиться

7 ответов

Это:

class GetSetExample
{
    public int someInt { get; set; }
}

действительно то же самое, что это:

class GetSetExample
{
    private int _someInt;
    public int someInt {
        get { return _someInt; }
        set { _someInt = value; }
    }
}

get ; set; синтаксис - это просто удобное сокращение для этого, которое вы можете использовать, когда геттер и сеттер не делают ничего особенного.

Таким образом, вы не раскрываете открытый член, вы определяете частный член и предоставляете получить / установить методы доступа к нему.

15
ответ дан 3 December 2019 в 14:11
поделиться

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

Упрощенное получение; установлен; дизайн был представлен в C # 2.0. Это в основном то же самое, что объявлять все с частным членом, поддерживающим это (декомпилируйте это с помощью инструмента, такого как Reflector, и посмотрите).

public int someInt{get;set;} 

прямо равняется

private int m_someInt;
public int someInt{
  get { return m_someInt; }
  set { m_someInt = value; }
} 

. Самое замечательное в использовании упрощенного геттера / сеттера - это то, что когда вы захотите дополнить реализацию чуть большим чутьем позже, вы не нарушите совместимость ABI.

Не беспокойтесь о том, что геттеры / сеттеры замедляют ваш код из-за косвенного обращения. В JIT есть вещь, называемая встроенной, что делает использование геттера / сеттера столь же эффективным, как прямой доступ к полю.

7
ответ дан 3 December 2019 в 14:11
поделиться

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

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

7
ответ дан 3 December 2019 в 14:11
поделиться

В вашем первом примере C # автоматически генерирует закрытые резервные поля, поэтому технически член данных не объявляется как общедоступный, только средство получения / установки.

4
ответ дан 3 December 2019 в 14:11
поделиться

В "чистом" объектно-ориентированном подходе вообще неприемлемо раскрывать состояние ваших объектов, и это применимо к свойствам, поскольку они реализованы в .NET и get_ set_ Properteis Java / EJB. Идея состоит в том, что, раскрывая состояние вашего объекта, вы создаете внешние зависимости для внутреннего представления данных вашего объекта. Чистый объектный дизайн сводит все взаимодействия к сообщениям с параметрами.

Вернемся к реальному миру: если вы попытаетесь применить такой строгий теоретический подход в работе, вас либо высмеют за пределами офиса, либо избьют до полусмерти. Свойства чрезвычайно популярны, потому что они представляют собой разумный компромисс между чисто объектным дизайном и полностью открытыми личными данными.

1
ответ дан 3 December 2019 в 14:11
поделиться

Это вполне разумно, и ваш профессор (без контекста) неправ. Но в любом случае использование «автоматических свойств» - это нормально, и вы можете сделать это независимо от того, являются ли они общедоступными или частными.

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

0
ответ дан 3 December 2019 в 14:11
поделиться

ваш профессор был совершенно прав.

Рассмотрим этот тривиальный пример того, почему следует избегать "геттеров": Может быть 1000 вызовов метода getX () в ваша программа, и каждый из этих вызовов предполагает, что возвращаемое значение имеет определенный тип. Возвращаемое значение getX () может быть обработано, например, в локальной переменной, и тип переменной должен соответствовать типу возвращаемого значения. Если вам нужно изменить способ реализации объекта таким образом, чтобы изменился тип X , у вас большие проблемы. Если X раньше было int , а теперь должно быть длинным , теперь вы получите 1000 ошибок компиляции. Если вы исправили проблему неправильно, приведя возвращаемое значение к int , код будет компилироваться чисто, но работать не будет. (Возвращаемое значение может быть усечено.) Вы должны изменить код, окружающий каждый из этих 1000 вызовов, чтобы компенсировать это изменение. Я, по крайней мере, не хочу выполнять такую ​​большую работу.

Holub On Patterns

0
ответ дан 3 December 2019 в 14:11
поделиться