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

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

Это....

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

vs Это...

class NonGetSetExample
{
    private int someInt;
}

Edit:

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

ОТВЕТЫ

Ответ 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 для доступа к нему.

Ответ 2

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

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

public int someInt{get;set;}

прямо равен

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

Большая часть о том, что у вас есть упрощенная система getter/setter, заключается в том, что, когда вы захотите заполнить эту версию немного позже, вы не нарушите совместимость с ABI.

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

 public MyVar{private get; public set;}

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

Ответ 7

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

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

Ответ 8

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

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

Holub On Patterns