在否决投票之前，让我解释一下我的问题。我在设计架构方面有一点经验，并尝试进步。一个，当我修复一个错误时，我得出了一个结论，我们需要使我们的private方法成为public并且比使用它。这是完成我的工作并修复错误的最快方法。我去找我的组长说。在我从他那里得到一个鬼脸之后，我被解释说每种public方法都是一种非常昂贵的乐趣。有人告诉我，在项目的整个生命周期中都应该支持每种方法。 以及更多..public
我想知道。的确！为什么当我查看代码时它不是那么清楚。当我设计自己的架构时，它也不是那么明显。我记得我对此的想法：
啊，我会离开这个方法
public，谁知道呢，也许当系统增长时它会派上用场。
我很困惑，并认为我制作了可扩展的系统，但实际上我的界面中有大量垃圾。
我的问题：
如果一种方法真的很重要并且值得去做，你怎么能向自己解释public呢？有什么反例可以检查吗？你是如何在private/public不花费数小时在星界上的情况下接受培训来做出选择的？
我建议你阅读 YAGNI http://c2.com/cgi/wiki?YouArentGonnaNeedIt
您应该编写代码以满足实际需求，因为编写代码以满足想象的需求会导致代码臃肿且难以维护。
我最喜欢的报价
达到完美，不是在没有什么可以添加的时候，而是在没有什么可以带走的时候。
-- Antoine de Saint-Exupery 法国作家 (1900 - 1944)
关于对象所在的域，您可以问自己几个问题：
封装通常被称为“数据隐藏”或“隐藏成员”，我认为这会导致很多混乱。没有经验的开发人员会正确地问：“我为什么要在我的其余代码中隐藏任何东西？如果它在那里，我应该能够使用它。毕竟这是我的代码。”
虽然我不太相信你的团队负责人的回应方式，但他有一个很好的观点。当对象之间的连接点太多时，最终会产生太多的连接。对象变得越来越紧密耦合并融合成一个无法支持的大混乱。
在整个架构中清晰而严格地保持关注点分离可以显着帮助防止这种情况发生。设计对象时，请考虑其公共接口的外观。他们会有什么样的外在可见的属性和功能？任何不能合理预期作为该功能的一部分的东西都不应该公开。
例如，考虑一个名为 a 的对象Customer。您会合理地期望一些描述 a 的属性Customer，例如：
您可能还期望一些可用的功能：
假设您在其中也有一些技术考虑Customer。例如，对象上的方法可能Customer通过类级连接对象直接访问数据库。该连接对象应该是公开的吗？好吧，在现实世界中，客户没有与之关联的数据库连接。所以，很明显，不，它不应该公开。这是一个内部实现问题，不属于Customer.
当然，这是一个非常明显的例子，但说明了这一点。每当您公开一个公共成员时，您都会为该对象添加外部可见的功能“合同”。如果您需要用另一个满足相同合同的对象替换该对象怎么办？在上面的示例中，假设您想创建一个将数据存储在 XML 文件而不是数据库中的系统版本。如果外部的其他对象Customer正在使用它的公共数据库连接，那就是个问题。您必须对整体设计进行更多更改，而不仅仅是Customer.
作为一般规则，通常最好先选择最严格的成员可见性，然后根据需要打开它们。将该指南与考虑对象的方法相结合，即根据它们所代表的真实世界实体以及这些实体上可见的功能，您应该能够针对任何给定情况确定正确的行动方案。
这个问题需要对 OOP 设计进行深入彻底的讨论，但我的简单回答是任何具有公共可见性的东西都可以被其他类使用。因此，如果您不构建供他人使用的方法，请不要将其公开。
不必要地将私有方法公开的一个陷阱是，当其他类确实使用它时，它会使您更难重构/更改方法，您必须维护下游（想想如果这发生在数百个类上）
但是，也许这个讨论永远不会结束。你应该花更多的时间阅读 OOP 设计模式书籍，它会给你更多的想法