封装的"巅峰" - 关于有效C++建议的问题

Question

有效C++的第23项规定:首选非成员非友元函数到成员函数.

该项目的整个目的是鼓励封装,以及封装灵活性和功能扩展性,但我的问题是,在采取这些建议时你走了多远？

例如,您可以拥有自己的类,私有数据成员,然后通过将公共函数仅减少为私有数据成员的访问者和/或更改者来采用极简主义方法.然后,每个其他功能都可以是非成员功能.

但是,您是否愿意在可能牺牲代码清晰度的情况下增加封装,并使用访问器和变换器？画线在哪里？

Answer 1

首先,并非所有人都同意这一建议.我不认为我见过任何人,只有Meyers(编辑:和Herb Sutter)给出了这个建议,我只是在C++的上下文中看到它.例如,在Java或C#中创建"非成员非朋友函数"实际上是不可能的,因为Java和C#没有自由函数,而Ruby开发人员(例如)更喜欢有意创建成员函数的"人性化接口"非成员可以做同样的事情,只是为了让那些功能的来电者的生活更轻松.

即使你接受了迈耶斯的建议,你也应该更喜欢非成员非朋友的功能到成员函数(我认为这是一个很好的建议,它确实帮助我更好地应用封装来考虑封装类的实现,即使是从其成员功能),这只是一个需要考虑的设计轴.

面向对象设计的关键概念是对象做某事.对象不仅仅是其他代码所做的一组setter和getter.相反,它应该附加行为 - 也就是说,它应该有做事情的方法 - 它应该封装它们如何做这些事情的细节.如果你按照这种方法使用OO,那么将Meyers的建议推向极致,因为你确实伤害了封装而不是帮助它:你最终通过getter和setter暴露所有类的内部实现变量而不是隐藏它们以便只有类的方法(负责代表类创建内容的代码,这是你开始使用类的唯一原因)可以实现它.

那么回答你关于迈尔斯的建议还有多远的问题:如果可以使用类的公共接口合理地将函数实现为非朋友的非成员函数,那么不要将函数转换为成员函数,但不要损坏类的公共接口并通过暴露实现来违反其封装,以避免使某些成员成为某个东西.并确保你平衡封装与其他问题和其他方法(包括,如果你的团队决定走这条路线,一个完整的人性化界面的利弊).