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