一段时间以来，我一直将类接口设计得最小化，与成员函数相比，我更喜欢命名空间包装的非成员函数。基本上遵循 Scott Meyer 在文章中的建议非成员函数如何改进封装 http://www.drdobbs.com/cpp/184401197.
我在一些小规模项目中这样做并取得了良好的效果，但我想知道它在更大范围内的效果如何。是否有任何大型的、备受推崇的开源 C++ 项目可供我查看，或许可以参考一下强烈遵循此建议的地方？
更新：感谢您的所有意见，但我对意见并不真正感兴趣，而是想了解它在更大范围内的实践中效果如何。尼克的答案在这方面最接近，但我希望能够看到代码。对实际经验（积极的、消极的、实际考虑因素等）的任何形式的详细描述也是可以接受的。
我在我从事的项目中经常这样做；我现在公司最大的有2M行左右，但不是开源的，所以无法提供参考。不过，总的来说，我会说我同意这个建议。您将不严格包含在一个对象中的功能与该对象分离得越多，您的设计就会越好。
举例来说，考虑经典的多态性示例：具有子类的 Shape 基类和虚拟 Draw() 函数。在现实世界中，Draw() 需要获取一些绘图上下文，并可能了解正在绘制的其他事物或一般应用程序的状态。一旦将所有这些放入 Draw() 的每个子类实现中，您可能会出现一些代码重叠，或者大部分实际的 Draw() 逻辑将位于基类中或其他地方。然后考虑一下，如果您想重用其中一些代码，则需要提供更多的接口入口点，并且可能会用与绘制形状无关的其他代码污染函数（例如：多形状绘制相关逻辑） ）。不久之后，它就会变得一团糟，你会希望有一个绘制函数，它需要一个 Shape（以及上下文和其他数据），而 Shape 只是具有完全封装的函数/数据，而不是使用或引用外部物体。
无论如何，这就是我的经验/建议，无论其价值如何。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
