Размышления Страуструпа про защищенные члены…
Sumo 04.03 23:03
/ 05.03 00:49
Из очень хорошей книги «Дизайн и эволюция языка C++
~~~~~~~~~~~
13.9. Защищенные члены
Простая модель сокрытия данных на основе закрытых и открытых секций класса прекрасно работала в C++, пока он использовался в основном как язык для абстрагирования данных. Данная модель была вполне пригодна и для большого
класса задач, где наследование применялось для объектноориентированного программирования. Однако, когда речь заходит о классах, выясняется, что к любому
из них обращаются либо производные от него классы, либо прочие классы и функции. Функциичлены и дружественные функции, реализующие операции с классом, воздействуют на его объекты от имени одного из этих «пользователей». Механизм открытых и закрытых членов позволяет четко различать автора класса и т.п., но не дает возможности приспособить поведение к нуждам производных классов.
Вскоре после выхода версии 1.0 ко мне в кабинет заглянул Марк Линтон и умолял добавить третий уровень контроля доступа, который напрямую поддержал бы стиль, применяемый в библиотеке Interviews (см. раздел 8.4.1). Она разрабатывалась в Стэнфорде. Мы выбрали слово protected для обозначения членов класса, которые вели себя как «открытые» для прочих членов самого этого класса и производных от него, но как «закрытые» для всех остальных «пользователей».
Марк был главным создателем библиотеки Interviews. Основываясь на опыте
и примерах из настоящих программ, он убедительно доказывал, что защищенные
данные абсолютно необходимы при проектировании эффективной и расширяемой инструментальной библиотеки для X Windows. Альтернативой защищенным
данным, по его словам, были неприемлемо низкая эффективность, неуправляемое
распространение встраиваемых интерфейсных функций или глобальные данные.
Защищенные данные и, в более широком смысле, защищенные члены казались
меньшим злом. Кроме того, так называемые чистые языки вроде Smalltalk поддерживали именно такую – довольно слабую – защиту вместо более сильной защиты C++, основанной на концепции private. Мне самому приходилось писать код, в котором данные были объявлены как public просто для того, чтобы ими можно было пользоваться в производных классах. Видел я также и программы, в которых концепция friend использовалась неудачно и лишь ради того, чтобы дать доступ явно поименованным производным классам.
Это были веские аргументы, убедившие меня в том, что защищенные члены надо разрешить. Однако «веские аргументы» могут найтись для каждого мысли
мого языкового средства и для любого возможного его использования. Нам же
нужны факты. Не имея фактов и должным образом осознанного опыта, мы уподобляемся греческим философам, которые на протяжении нескольких веков велиблистательные дискуссии, но так и не смогли договориться, из каких же четырех (а может, пяти) основных субстанций состоит Вселенная.
Примерно через пять лет Марк запретил использование защищенных членов
данных в Interviews, поскольку они стали источником ошибок и серьезно усложнили сопровождение. В пленарном докладе Барбары Лисков (Barbara Liskov) на
конференции OOPSLA [Liskov, 1987] достаточно подробно описываются теоретические и практические проблемы, связанные с контролем доступа на основе
концепции protected. Мой опыт показывает, что всегда существовали альтернативы размещению информации в общем базовом классе, где она была бы доступной производным классам. Я сомневался по поводу protected еще и потому, что
при небрежном программировании общий базовый класс слишком уж легко использовать как разновидность глобальных данных.
К счастью, вас никто не принуждает пользоваться защищенными данными в C++. По умолчанию члены класса имеют атрибут private, и обычно такой выбор лучше. Замечу, впрочем, что ни одно из этих возражений не относится к защищенным членамфункциям. Убежден, что protected прекрасно подходит для специфицирования операций, которыми можно пользоваться в производных классах.
Защищенные члены появились в версии 1.2. Защищенные базовые классы были впервые описаны в ARM и включены в версию 2.1. Оглядываясь назад, я думаю, что protected– это тот случай, когда «веские аргументы» и мода сбили меня с пути истинного и заставили отказаться от своих убеждений ради новых
возможностей.
~~~~~~~~~~~
Дополню разработчика самого универсального языка программирования… Чем меньше мы мешаем программистам пользоваться нашими объектами, тем лучше. Чем больше я программирую тем чаще делаю все переменные публичными. :)
