Как часто вы видите злоупотребление сокращенными геттерами/сеттерами C#?

Question

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

public int FooBar { get; set; }

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

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

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

Answer 1

Я видел, как этим злоупотребляли (по моему мнению).В частности, когда разработчик обычно писать:

private readonly int foo;
public int Foo
{ 
    get 
    { 
        return foo;
    }
}

иногда пишут:

public int Foo { get; private set; }

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

К счастью, теперь это доступно начиная с C# 6:

// Foo can only be set in the constructor, which corresponds to a direct field set
public int Foo { get; }

Answer 2

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

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

Было бы неплохо, если бы существовал «правильный» вариант только для чтения, и если бы вам не нужно было использовать :this() ctor-chaining на структурах, но....ме!

Answer 3

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

Answer 4

Я не думаю, что автоматические свойства хуже обычных свойств в отношении инкапсуляции.

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