Является ли использование get set свойствами C# считается хорошей практикой?

Question

мой вопрос прост, использует ли свойства get C# считаться хорошим, лучше, чем писать методы getter и setter? Когда вы используете эти свойства, вам не нужно объявлять своих членов данных класса общедоступными? Я спрашиваю об этом, потому что мой профессор заявил, что члены данных должны никогда не объявлять, поскольку это считается плохой практикой.

Это ....

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

против это ...

class NonGetSetExample 
{ 
    private int someInt; 
} 

Edit:

Спасибо всем вам! Все ваши ответы помогли мне, и я, соответственно, проголосовал за ваши ответы.

Answer 1

Это:

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Упрощенный get; задавать; дизайн был введен в 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 есть вещь, называемая inlineing, которая использует метод getter/setter так же эффективно, как и прямой доступ к полям.

Answer 5

В «чистом» объектно-ориентированном подходе не считается полностью открытым состояние объектов, и это относится к свойствам, поскольку они реализованы в .NET и get_ set_ properteis Java/EJB. Идея состоит в том, что, обнажая состояние вашего объекта, вы создаете внешние зависимости для внутреннего представления данных вашего объекта. Конструкция чистого объекта уменьшает все взаимодействия с сообщениями с параметрами.

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

Answer 6

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

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

Answer 7

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

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

Holub On Patterns

Answer 8

, потому что с членом общественной данных, что элемент данных может быть изменен или может быть считан из класса и вы не можете контролировать операции чтения/записи операции доступа, но со свойствами, вы можете контролировать чтения/записи поток для примера рассмотрим следующее выражение:

public MyVar{private get; public set;} 

означает значение MyVar может быть изменено только внутри класса и может быть считан из класса (читать в частном порядке и читать публично), и это не является р ossible только с публичными данными