c++ - "Pinnacle"of Encapsulation - 关于Effective C++ Advice的问题

Question

Effective C++ 的第 23 条规定:将非成员非友元函数优先于成员函数。

该项目的全部目的是鼓励封装，以及包的灵 active 和功能的可扩展性，但我的问题是，在接受这个建议时，你能走多远？

例如，您可以拥有自己的类、私有(private)数据成员，然后采用极简主义方法，将公共(public)函数减少为仅用于私有(private)数据成员的访问器和/或修改器。然后，每个其他函数都可以是非成员函数。

但是，您是否愿意以可能牺牲代码清晰度为代价增加封装，到处都是访问器和修改器？线画在哪里？

Answer 1

首先，并不是每个人都同意这个建议。除了 Meyers(edit: 和 Herb Sutter)，我认为我没有见过任何人提供此建议，而且我只看到它是在 C++ 的上下文中给出的。例如，在 Java 或 C# 中创建“非成员非友元函数”实际上是不可能的，因为 Java 和 C# 没有自由函数，而 Ruby 开发人员(例如)更喜欢 "humane interfaces"故意创建成员函数来做非成员可以做的事情，只是为了让这些函数的调用者的生活更轻松。

即使您确实接受了 Meyers 的建议，您应该更喜欢非成员非友元函数而不是成员函数(我认为这是一个很好的建议，它确实帮助我更好地应用封装来考虑封装类的实现，甚至来自其成员函数)，这只是要考虑的设计轴之一。

面向对象设计的关键概念是对象做某事。对象不仅仅是其他代码执行的一组 setter 和 getter。相反，它应该附加行为——也就是说，它应该有做事情的方法——并且它应该封装它如何做这些事情的细节。如果您遵循这种 OO 方法，那么像您那样将迈耶斯的建议发挥到极致会伤害封装而不是帮助它:您最终会通过 getter 和 setter 公开类的所有内部实现变量，而不是隐藏它们，这样只有类的方法(负责代表类做事的代码，这是你有一个类开始的唯一原因)可以得到它。

所以回答你的问题，即迈耶斯的建议能走多远:如果可以使用类的公共(public)接口(interface)，但不要破坏类的公共(public)接口(interface)并通过公开实现来违反其封装只是为了避免使某些东西成为成员。并确保平衡封装与其他问题和其他方法(包括，如果您的团队决定走那条路，成熟的人性化界面的利弊)。