Каково было объяснение позади представления спецификатора защищенного доступа в C++. Пример был бы полезен.
Уровень доступа protected
используется, когда классы должны работать вместе со своими наследниками.
Например, представьте себе абстрактный класс Shape
, который может сообщать свою площадь внешнему миру.
Различные формы, такие как треугольники, квадраты и круги, описываются по-разному (угол, сторона, радиус) и рассчитывают их площади по-разному.
Класс Shape
может иметь общедоступный метод getArea ()
, который возвращает частную переменную, содержащую область.
Лучшим способом установки этой переменной был бы метод protected
с именем setArea (double)
, который будет вызываться дочерними классами.
Таким образом, Circle
вызовет setArea (PI * radius * radius)
, Square
вызовет setArea (side * side)
и т. д.
Обратите внимание, что это не обязательно хороший дизайн (но это отличный пример protected
)
Для подобных вопросов я рекомендую Дизайн и эволюция C ++ Бьярна Страуструпа. В разделе 13.9 описывается эволюция защищенных членов.
Вскоре после выпуска 1.0 [Cfront] Марк Линтон зашел в мой офис и страстно призвал к третьему уровню контроля доступа [...] Он убедительно аргументировал это, основываясь на реальном опыте и примерах из реального кода, защищающего данные был необходим для разработки эффективного и расширяемого набора инструментов X windows. [...] Это были хорошие аргументы и, по сути, те, которые убедили меня допустить защищенных членов. [...]
Примерно пять лет спустя Марк запретил использование защищенных элементов данных в Интервью [ упомянутом ранее наборе инструментов X windows ], потому что они стали источником ошибок. [...] Они также серьезно усложняют обслуживание [...]
Защищенные элементы были введены в Релиз 1.2. Защищенные базовые классы впервые были описаны в версии 2.1. Оглядываясь назад, я думаю, что
protected
- это случай, когда «веские аргументы» и мода превзошли мое здравое суждение и мои практические правила принятия новых функций.