一些程序员说,"朋友功能打破了C++中的封装".一些程序员还说,"朋友的功能不会破坏封装;相反,他们自然会扩展封装屏障"
这是什么意思?..
如果朋友函数打破了C++中的封装,那么如何?
Nav*_*een 25
引用C++常见问题解答,我认为很好地描述了与朋友的情况和封装.
没有!如果使用得当,它们会增强封装效果.
当两个部分具有不同数量的实例或不同的生命周期时,您经常需要将一个类分成两半.在这些情况下,这两个半部分通常需要直接相互访问(这两个部分曾经在同一个类中,因此您没有增加需要直接访问数据结构的代码量;您只需重新调整代码分为两类而不是一类).实现这一目标的最安全的方法是让两半成为彼此的朋友.
如果您使用刚刚描述的朋友,您将保密私人物品.不理解这种情况的人经常做出天真的努力以避免在上述情况下使用友谊,并且通常他们实际上破坏了封装.它们要么使用公共数据(怪诞!),要么通过公共get()和set()成员函数使数据在两半之间可访问.只有当私有数据从类外部"有意义"时(从用户的角度来看),拥有私有数据的公共get()和set()成员函数才是正常的.在许多情况下,这些get()/ set()成员函数几乎与公共数据一样糟糕:它们隐藏(仅)私有数据的名称,但它们并不隐藏私有数据的存在.
Cod*_*ile 17
有些人说"朋友"打破封装的原因是因为封装数据和功能的全部意义在于没有其他任何需要查看数据的内容,但是朋友们让其他类看到内部.
我个人认为朋友们不会破坏包围,因为课程不应该完全依赖,而是相互依赖.
以汽车为例.我们通常使用它作为抽象模型,说我们不需要知道发动机是如何工作的,知道推动油门踏板就可以了.这是封装的整个概念,其中只有我们需要与类交互的函数才是我们需要了解的唯一函数.
然而,机械师类肯定需要了解汽车的具体内部工作原理,但将机械师构建成汽车是没有意义的.
这就是朋友进来的地方.你让机械师成为引擎,刹车或其他任何需要修理的朋友,他可以解决它.如果他所能做的只是压气/刹车,他无法修复它.
封装意味着您无法看到内部的内容,这friend意味着您可以看到内部.因此,根据您的观点,friend要么打破封装(通过让朋友看到内部),要么扩展封装(通过让开发人员放松对特定朋友的障碍).
FWIW,一个好的经验法则是说只应该将嵌套/内部类声明为朋友; 这个规则可以概括为"没有长途朋友",即类的朋友(如果有的话)应该在与类本身相同的头文件中声明.
| 归档时间: |
|
| 查看次数: |
8269 次 |
| 最近记录: |