首先,不是每个人都同意这个建议。除了 Meyers(编辑:和Herb Sutter )之外,我认为我没有见过任何人给出这个建议,而且我只看到它是在 C++ 的上下文中给出的。例如,在 Java 或 C# 中创建“非成员非友元函数”实际上是不可能的,因为 Java 和 C# 没有自由函数,而 Ruby 开发人员(例如)更喜欢有意创建成员函数的“人性化接口”做同样的事情非成员可以,只是为了让这些函数的调用者生活更轻松。
即使您确实接受了 Meyers 的建议,您应该更喜欢非成员非朋友函数而不是成员函数(我认为这是一个很好的建议,它确实帮助我更好地应用封装,以考虑封装一个类的实现,甚至从它的成员功能),这只是一个需要考虑的设计轴。
面向对象设计的关键概念是对象做某事。一个对象不仅仅是其他代码用来处理的一袋 setter 和 getter。相反,它应该附加行为——也就是说,它应该有做事的方法——并且它应该封装它如何做这些事情的细节。如果您遵循这种面向 OO 的方法,那么将 Meyers 的建议发挥到极致会损害封装而不是帮助封装:您最终会通过 getter 和 setter 公开所有类的内部实现变量,而不是隐藏它们,以便只有类的方法(代表类负责做事的代码,这是你有一个类开始的唯一原因)可以得到它。
因此,要回答您对迈耶斯的建议采取多远的问题:如果可以使用类的公共接口将函数合理地实现为非友元非成员函数,则不要将函数不必要地转换为成员函数,但不要损坏类的公共接口并通过公开实现来违反其封装只是为了避免使某些东西成为成员。并确保在封装与其他关注点和其他方法之间取得平衡(包括,如果您的团队决定走这条路,完整的人性化界面的优缺点)。