什么时候应该把方法变为私有？
有很多时候我不确定一个特定的方法是否应该被私人化。 例如，我正在build立一个类，它负责生成一个报告。 这个类有一个buildReport方法和几个为buildReport收集必要数据的方法。
// single public method // uses a set of helper methods public buildReport() // helper methods private avgSurveyTime() private fetchVendors() private fetchSendCounts() private ... 我在辩论是否应该公开这些辅助方法。 我真正计划在外面调用的唯一方法是buildReport() 。 但是，使用fetchVendors()等方法获取供应商列表可能会很有用。
我看到这样两个思想stream派：你总是可以尽可能less地暴露。 （在这种情况下，我的许多类只能有一个公共方法），或者你可以公开所有可能对class级用户有用的东西。
是否有一个好的经验法则来决定什么时候应该公开/私有的方法？
我遵循的唯一规则是尽量less公开。
这样看。 你可以随时做一些事情公开 – 它不会破坏任何现有的代码。 试图使某些公开的私有事物最终可能会破坏很多现有的代码。
如果有人想从你的课程中获得更多的function，那么他们可以提出请求，并且可以公开他们需要的东西。 有机会，他们会想要的东西与你已经有了微妙的不同，所以你需要一个新的界面。
一个有用的指导技巧是在你开始实现之前为你的类写一个接口。 然后在实现的时候，告诉自己一个不在接口中的方法应该是私有的，或者根本不在这个类中。
如果您在devise课程合同的时候不知道需要在那里的方法，那么它可能不应该成为其公共接口的一部分。
-
你应该只向外界揭露外界真正需要的东西。 在需要的时候 ，而不是一开始就给class级的消费者增加function。 目前的智慧是避免预先devise 。 （ 见YAGNI ）
-
拥有类内其他function所使用的公共方法当然也是可以接受的。 但是，这应该被认为是一个轻微的难闻的气味 。 这可能意味着你的class级正在尝试做太多事情。
我的猜测是让你的课程保持原样。 然后，当外部世界需要这些其他更小的方法时，考虑是否应该分开你的课程。 如果每个类的目的是为了产生一个报告，那么你不应该从这个对象中暴露这些方法。 相反，将“较小”的方法放到一个通用的帮助类中。 这样一来，它们就可以被外部使用，而不会从根本上改变现有报告类的性质。 简而言之：
不要只是这样做，因为你认为这可能会有所帮助 。 如果/当需要附加function时，请重新考虑您的总体devise以适应新的要求。
公共和私人的方法是非常不同的野兽。 在公开方法之前请小心。
- 公共方法必须validation其所有参数。
- 他们必须妥善logging，包括他们可能抛出的任何例外。
- 所有的边缘情况必须分析和处理（在代码或文件）。
- 涉及调用公共方法的顺序的任何要求都必须形成文件，或者最好删除。
- 对象状态需求也必须被logging和validation。
- 公共方法不得以任何可能在从一个版本移动到另一个版本时破坏应用程序的方式来改变它们的签名或行为。
- 公共方法可能需要与编组要求一起devise。 （如.Net的CLS限制。）
私有方法没有这些限制。
如果课堂之外不需要，那么就在这个时候，把它变成私人的。 如果后来是这样，你可以根据需要保护或公开。
如有疑问 – 请将其私人化。
如果这个class级是在你的组织内部使用的，也就是说你不是把这个class级作为一般用途的图书馆来发行，那么我衷心地同意你应该尽可能多地私下或者保护。 如果后来你发现其他一些类需要访问一个私有函数，那么在那个时候把它改为public。 这并不难。
我唯一的警告就是，如果这是你“发布”的东西，那些没有直接改变的人将会使用它。 那么你需要仔细想出一个完整的API。
但是如果没有这个，只需编写你需要的代码即可。 不要编写你认为有可能使用的函数。
一般而言，您应该尽可能less地暴露，并尽可能地保密。
如果你犯了一个错误，隐藏你应该暴露的东西，没有问题，只是公开。 但是，如果你公开某个东西，然后再决定它应该是私有的，那么你可能会遇到问题，因为现在公共方法可能被其他许多类使用。
您可以自由地更改私有方法的实现，而不会有任何外部影响。 如果你有所有的公开课，这可能是不可能的，因为这些方法可以被你的课外的某些东西使用。
我总是遵循这个：“ 明天的devise，今天的代码 ”。
如果今天你只需要一个公共方法，那么只保留一个公共方法。
规则是应该提供一种方法，除非需要。 其中一个主要原因是，在未来的API等版本中，你总是可以公开一个私有的函数，但是如果不破坏已经存在的代码，你几乎可以永远不会使之前的公有函数成为私有的。
没有包含在类的接口中的所有东西都必须是（真的）是私有的。 如果您不确定该类的接口是什么（例如，您不是http://www.artima.com/lejava/articles/designprinciples.html）编程接口或这些接口尚未完全定义，请启动;一切都是私密的，并根据需要公开，保护，私人包装等。
但仔细想想！ 一旦某些东西可以被其他代码访问，那么这个代码和这个类之间就存在依赖关系，重构就受到了限制。 经验法则：只公开那些定义抽象的方法，而不是如何实现。
简单的规则：
-
如果您不想在使用它的类之外暴露它，请将其设置为“ PRIVATE” 。
-
如果您正在寻找在同一个程序集中暴露给其他类而不是在程序集之外，请将其设置为INTERNAL （C＃）/ Friend （VB.NET）。
-
如果您正在寻求将大会之外的function公开给大家，请将其公开
我正在研究一个由两个主要组成部分组成的系统：从各种来源导入数据并生成报告。 问题是，整个事情是由缺乏基本的面向对象devise技能的人devise的。 在同一个“类”中，他们有“私有”方法来从数据库中读取数据，调用“私有”方法来validation所述数据，这些数据也被另一个“私人”500行函数调用整个应用程序简单地格式化数据。
您应该从处理页面布局的实际类中移除private avgSurveyTime（）private fetchVendors（）private fetchSendCounts（）。
