Мне кажется, что использование функции friend
- это небольшая хитрость. Нарушают ли функции friend
концепцию инкапсуляции?
Какие есть альтернативы функции friend
? Поможет ли использование простого вспомогательного класса / функции вместе с функциями-членами сеттер и добытчик улучшить инкапсуляцию по сравнению с простым использованием friend
?
@GuillaumeRacicot: Но будет ли совместное использование такого secret keys
с другими позже создавать путаницу в коде (особенно в больших проектах) - постоянство функций-членов и т. д.
Скотт Мейерс написал ряд статей о функциях-членах, друзьях, не являющихся членами, и друзьях, не являющихся членами, и о том, как они могут повлиять на инкапсуляцию. Вы сможете найти приличное количество с помощью Google. Некоторые детали его мышления со временем изменились. Имейте в виду, что инкапсуляция сама по себе не является желательным свойством - это один из способов контроля и локализации эффектов изменений и, следовательно, способствует таким свойствам, как гибкость (способность контролировать изменения) и надежность (не вносить непреднамеренных недостатков при внесении изменений. ).
Этот вопрос не основан на мнении, если вы измеряете степень инкапсуляции как объем кода, который компилятор разрешает доступ к другому фрагменту кода.
Do
friend
functions violate the concept of encapsulation?
Фактически, это не. Во-первых, обратите внимание, что он не нарушает инкапсуляцию больше, чем члены public
. Являются ли члены public
нарушением концепции инкапсуляции? Очевидно нет. Более того, во многих ситуациях friend
увеличивает инкапсуляцию, а не нарушает ее, поскольку он позволяет вам поддерживать материал private
как private
, вместо того, чтобы предоставлять данные в масштабе всей системы с использованием членов public
, что делает всю концепцию private
скрытой от невооруженным глазом. Это противоположно выражению намерения в вашем коде, и, когда вы его заметите, это должно вызвать тревогу. friend
позволяет смягчить эту проблему, поскольку дает вам контроль над тем, кто именно может получить доступ к этим членам, которые хранятся в private
, чтобы все знали о них. В C++ FAQ приводится один пример, в котором вы можете использовать friend
для решения проблемы проектирования, чтобы вы осуществляли этот контроль над доступом к точке, где вы не увеличили вообще количество кода, имеющего доступ к частям private
.
Shouldn't a simple helper class/function along with setter & getter member functions can rescue this design flaw ?
Что ж, использование вспомогательного класса определенно могло бы удовлетворить некоторые из тех же потребностей, что и friend
, но во многих случаях это неоправданно более громоздко, чем просто использование friend
. Что касается функции или геттера / сеттера, это звучит для меня как использование членов общественный для прямого раскрытия членов частный, недостатки которых описаны выше.
... or shouldn't it be treated as a poor design practice ?
В заключение постарайтесь избегать здесь субъективных вопросов, например, следует ли рассматривать что-либо как X. Давайте придерживаться фактов! :)
Does friend function violates concept of encapsulation
Нет, это инкапсуляция усиливает, потому что альтернативой было бы сделать член public
.
Ну, простой класс только с геттером и сеттером ... ничем не отличается от того, что эти члены являются общедоступными. Вы лжете только себе. Функция друга на самом деле более полезна для инкапсуляции, поскольку вы напрямую нацелены на то, кто может получить доступ к вашим участникам.