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

Question

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

Почему следующее никогда не используется (по крайней мере, яникогда не видел):

private Name { get; set; }

Я просмотрел документацию MSDN и прочитал несколько учебных пособий, касающихся автоматически реализуемых свойств, но, похоже, нет никаких советов относительно их плюсов и минусов и когда им следуетизбегать.Влияет ли автоматически внедряемое свойство на безопасность программы?Есть ли ситуации, когда их следует избегать?В каких ситуациях они являются идеальным выбором?

Спасибо.

Answer 1

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

Как сказал Алан Кей :

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

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

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

Answer 2

Вы спрашивали себя почему вас всегда учили, что это хорошая идея сделать членов приватными?

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

Выделив свойство из подробностей о «хранилище на основе памяти», мы получили большое количество преимуществ. В первую очередь - мы можем переопределить поведение получения и установки без нарушения какого-либо кода, который использует это свойство. Мы также можем использовать это свойство в качестве абстракции для извлечения данных из нескольких различных реализаций. Это становится чрезвычайно полезным для тестирования / насмешек и обеспечения альтернативного хранилища. Если другие классы зависят от деталей реализации «хранения памяти», вы не сможете изменить поведение вашего класса, не нарушив все это.

До появления авто свойств мы обычно сохраняли поле и создавали метод получения и установки для его инкапсуляции по причинам, описанным выше. Свойство auto автоматизирует это для нас. Мы могли бы написать код, который обычно использует поля повсюду в коде, но мы придерживаемся идеи: «Сейчас я сделаю это как поле, но это может измениться позже, если критерии изменятся».

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

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

Answer 3

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

Вы должны думать о них как о частных полях с публичными методами get и set в C ++. Это роль для свойств на C #.

Answer 4

Автоматически реализованные свойства - это всего лишь ярлык для общего шаблона. Каждый раз, когда у вас будет закрытый член с соответствующими функциями get и set в C ++, вы можете сделать то же самое с помощью свойства auto в C #. Они не представляют никакой другой передовой опыт или проблемы безопасности.

Answer 5

Автоматически реализованные свойства имеют закрытого участника. Компилятор добавляет их для вас. Это просто ярлык для

private int _aMember;
public int AMember {
           get {return _aMember;} 
           set {_aMember = value;} 
}

Вы используете их, у вас нет реальной логики в геттере / установщике (кроме необходимости инкапсулировать).

Answer 6

Свойства не являются данными "member".Они являются типом вашего

const T& field() const;
T& field();

типа вещей, или методов get и set, т.е. они являются аксессорами.

Если вам не нужен член, не выражайте ихсвойства.В случае с автоматически генерируемыми вы можете просто (начиная с C # 2.0 afaik) написать

int SomeProperty { get; private set; }