C# с использованием сеттеров или геттеров из базового класса

Question

Рекомендуется ли устанавливать переменные-члены базового класса в защищенные, чтобы подклассы могли обращаться к этим переменным? Или более рекомендуется устанавливать частные переменные-члены и позволить подклассам получать или устанавливать переменную с помощью геттеров и сеттеров?

И если рекомендуется использовать метод геттеров и сеттеров, когда используются защищенные переменные?

Answer 1

Это очень аналогичный до this question, о том, получать ли доступ к информации в пределах одного класса через свойства или прямой доступ. Вероятно, стоит прочитать все эти ответы.

Лично мне не нравятся какие-либо поля, которые не являются частными, при случайном исключении статических полей readonly с неизменяемыми значениями (независимо от того, const или нет). Для меня свойства просто дают лучшую степень инкапсуляции. Как хранятся данные, это реализация решение, а не API решение (в отличие от свойств). Почему класс Foo, вытекающий из класса Bar, заботится о реализации класса Bar?

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

С автоматически реализованными свойствами в C# 3.0 проще, чем когда-либо раньше, превращать поля в свойства. Там очень мало причин не, чтобы сделать это.

Answer 2

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

Обычно вы должны указывать их как личные и использовать для геттеров/сеттеров.

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

EDIT: Я сделал некоторые профилирования и, по-видимому, даже в режиме Release, может быть разница в 20% между полями и свойствами. См. Мой пример: http://pastebin.com/m5a4d1597

Answer 3

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

Answer 4

Я должен согласиться с Джоном.

Но, в некоторых случаях я использую защищенную переменную для класса «top most» наследования. Например, если у вас есть объект, который является readonly, и вы не можете его установить, но вы можете использовать его в дочернем классе, я не понимаю, почему у меня должен быть защищенный Get для доступа к этой переменной. Простая защищенная переменная выполняет ту же инкапсуляцию, потому что вы не можете установить эту переменную, и вы можете получить доступ к этой переменной только из дочернего класса.

Но установите/получите способ сделать для другой ситуации.