Необходимо ли когда-либо использовать защищенные членские переменные?

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

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

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

, Если ситуация возникает, где мне нужен доступ к той частной переменной или методу от производного класса, я изменяю его от частного до защищенного.

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

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

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

единственные реальные исключения к этому - то, если Вы находитесь в бизнесе поставки двоичного dll's в форме черного ящика третьим лицам. Это состоит в основном из Microsoft, тех 'Пользовательских поставщиков' Управления DataGrid, и возможно нескольких других крупных приложений, которые поставлются с библиотеками расширяемости. Если Вы не находитесь в той категории, не стоит расходовать время/усилие для волнения о такого рода вещи.

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

Вот то, что Ваш суперкласс не может делать после создания членской переменной, защищенной а не частной со средствами доступа:

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

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

3. Набор точка останова или добавляет вывод отладки, когда переменная считана или записана в.

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

В целом, я думаю, что это был бы редкий случай, что я рекомендую делать защищенную членскую переменную. Вы - более обеспеченные расходы несколько минут, представляя свойство через методов get/методы set, чем несколько часов спустя разыскивающий ошибку в некотором другом коде, который изменил защищенную переменную. Не только, что, но и Вы обеспечиваетесь против добавления будущей функциональности (такой как ленивая загрузка), не повреждая зависимый код. Более трудно сделать это позже, чем сделать это теперь.

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

, Но у меня есть один хороший пример: Скажем, Вы можете некоторый универсальный контейнер. Это имеет внутреннюю реализацию и внутренние средства доступа. Но необходимо предложить по крайней мере 3 открытого доступа его данным: карта, hash_map, подобный вектору. Тогда у Вас есть что-то как:

template <typename T, typename TContainer>
class Base
{
   // etc.
   protected
   TContainer container ;
}

template <typename Key, typename T>
class DerivedMap     : public Base<T, std::map<Key, T> >      { /* etc. */ }

template <typename Key, typename T>
class DerivedHashMap : public Base<T, std::hash_map<Key, T> > { /* etc. */ }

template <typename T>
class DerivedVector  : public Base<T, std::vector<T> >        { /* etc. */ }

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

Сводка Таким образом, Вы защитили данные, используемые производным классом. Однако, мы должны взять интервал o, считают факт, Базовый класс должен быть абстрактным.

Короче говоря, да.

Защищенные членские переменные предоставляют доступ к переменной от любых подклассов, а также любых классов в том же пакете. Это может быть очень полезно, специально для данных только для чтения. Я не полагаю, что они когда-либо необходимы однако, потому что любое использование защищенной членской переменной может копироваться с помощью переменной члена парламента, не занимающего официального поста и нескольких методов get и методов set.

Для подробной информации о.Net модификаторах доступа идут сюда

нет никаких реальных преимуществ или недостатков к защищенным членским переменным, это - вопрос того, в чем Вы нуждаетесь в своей определенной ситуации. В целом это - принятая практика, чтобы объявить членские переменные как частные и включить внешний доступ через свойства. Кроме того, некоторые инструменты (например, некоторые картопостроители O/R) ожидают, что данные объектов будут представлены свойствами, и не распознают общедоступные или защищенные членские переменные. Но если Вы знаете, что хотите, чтобы Ваши подклассы (и ТОЛЬКО Ваши подклассы) получили доступ к определенной переменной, нет никакой причины не объявить его, как защищено.

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

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

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

Методы доступа / мутатора предлагают значительно большую стабильность API и гибкость реализации при обслуживании.

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

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