我们为什么要避免公开的方法?封装的好处

我建议你阅读YAGNIhttp://c2.com/cgi/wiki?YouArentGonnaNeedIt

您应该编写适合实际需求的代码，因为编写适合想象中的需求的代码会导致代码膨胀，更难维护。

我最喜欢的报价

完美是实现的，不是当没有什么可补充的时候，而是当没有什么可带走的时候。

--法国作家安托万·德·圣埃克苏佩里（1900-1944）

这个问题需要对OOP设计进行深入彻底的讨论，但我的简单答案是任何具有公共可见性的东西都可以被其他类使用。所以，若你们并没有为其他人构建方法，就不要公开它。

不成功地公开私有方法的一个陷阱是，当其他类确实使用了它时，它会使你更难重构/更改方法，你必须维护下游（想想如果这种情况发生在数百个类上）

然而，也许这场讨论永远不会结束。你应该花更多的时间阅读OOP设计模式书，它会给你更多的想法

关于对象所在的域，您可以问自己几个问题：

• 该成员（方法、属性等）是否需要其他对象访问
• 其他对象是否有任何业务访问此成员

封装通常被称为"数据隐藏"或"隐藏成员"，我认为这会导致很多混乱。没有经验的开发人员会理所当然地问："我为什么要对我的代码的其余部分隐藏任何东西？如果它在那里，我应该能够使用它。毕竟这是我的代码。"

虽然我真的不相信你的团队领导的回应方式，但他说得很好。当对象之间的连接点过多时，最终会产生过多的连接。对象变得越来越紧密地耦合，并融合成一个无法支撑的大混乱。

在整个体系结构中清晰而严格地保持关注点的分离可以显著地帮助防止这种情况的发生。当你设计你的对象时，考虑一下它们的公共接口会是什么样子。他们会有什么样的外在可见的属性和功能？任何不能合理预期作为该功能一部分的东西都不应该公开。

例如，考虑一个名为Customer的对象。您可以合理地期望一些描述Customer的属性，例如：

• 名称
• 地址
• 电话号码
• 已处理订单列表
• 等等

您可能还期望一些可用的功能：

• 处理付款
• 保留所有订单
• 等等

假设您在Customer中也有一些技术方面的考虑。例如，Customer对象上的方法可能通过类级连接对象直接访问数据库。该连接对象应该是公共的吗？在现实世界中，客户没有与之相关的数据库连接。所以，很明显，不，它不应该是公共的。这是一个内部实现问题，它不是Customer的外部可见接口的一部分。

当然，这是一个非常明显的例子，但说明了这一点。每当您公开一个公共成员时，您都会为该对象添加向外可见的功能"契约"。如果你需要用另一个满足相同合同的对象来替换这个对象，该怎么办？在上面的例子中，假设您想要创建一个将数据存储在XML文件而不是数据库中的系统版本。若Customer之外的其他对象正在使用它的公共数据库连接，那个就有问题了。除了Customer的内部实现之外，您还需要对整体设计进行更多的更改。

通常情况下，最好先选择最严格的成员可见性，然后根据需要进行开放。将该指南与根据对象所代表的真实世界实体以及这些实体上可见的功能来思考对象的方法相结合，您应该能够确定任何特定情况下的正确行动方案。