我们什么时候应该使用公共的，什么时候应该使用私有的？

Question

当我们在我们的团队解决方案中实现目前未被其他类使用的方法时，访问修饰符应该是公共的还是私有的？ 我相信“一个公共成员说这个成员代表了这个对象提供的关键的、记录在案的功能。”。我们只将“实现细节”方法设为私有，所有将来可能有用的方法都应该公开，即使现在其他类中没有我们方法的消费者。但是我的对手说这样的方法应该是私有的。你觉得怎么样？

添加： 让我们更具体一点。例如有一个类SqlHelper。 其中有用于操作 SQL Server 的有用功能。 特别是使用到 SQL 服务器的连接。但不仅在那个班级。

例如，我需要实现将处理 SqlExeptions 的公共静态 HandleSqlExeption 方法（现在仅适用于 SqlHelper 类）。但我希望在所有在异常处理中使用 SQL 连接进行操作的类中都将使用此方法（而不是简单，例如： 捕捉（异常）{ MsgBox {“SqlError”}； 正如某处现在发生的那样。所以我认为公共访问修饰符会告诉其他同事他们可以使用这种方法。而 private 将隐藏该方法。如果有人要求使用这种方法，我将需要更改代码并重新构建程序集。为什么？只有负面的。

Answer 1

一般来说，您应该使用尽可能少的许可访问修饰符进行编码。

• 如果方法不在类外使用，则设为private。
• 如果方法需要继承类型使用，则设为protected。
• 如果该方法只在程序集中使用，请将其设为internal。
• 仅当方法要在程序集之外使用时，它才应该是public。

这对information hiding 有帮助，让您可以随意更改实现。

我听说这被描述为保护你的隐私。

---

在 API 设计方面，您应该有一个完整的 API，将所有逻辑功能公开为 public - 这就是为什么您应该在 .NET 中使用接口进行 API 设计的原因，因为所有接口成员都必须是 public。在实现类时，对不属于接口的任何成员使用上述经验法则 - 除非它们构成接口的逻辑部分，就其使用者而言。

---

因此，如果您今天使用了Read 方法，那么您应该有一个具有相同 可访问性的补充Write 方法。这是一个很好的设计（对称且符合预期），但是如果公共方法使用它们，如何您阅读或写入的方式应该隐藏在私有方法后面。

Answer 2

根据名称描述的方法的性质使用公共和私有。

public当方法可以暴露给其他对象和

private 当方法不应该被其他对象访问时。

如果您的对象需要更安全，请使用private 访问说明符。您还应该了解protected 访问说明符，它的不同之处在于，这些方法只能由继承它们的对象访问。

Answer 3

如果一个类有一些东西要暴露给外界，那么就让它公开，否则就是私有的。这取决于类的功能和目的，而不是当前或未来的要求。

Answer 4

这是一个判断电话。一般来说，如果它在逻辑上是类为获取它提供的功能而呈现的接口的一部分，那么即使它没有当前用户，它也应该是公共的。这将减少每次您想要将其用于您已经在使用它的基本相同的事情时都需要修改该类的机会。

但是，这是有代价的。您公开的每个功能都是您承诺提供的功能。如果将来您决定将其从公共界面中删除，您可能会破坏调用者。

例如，考虑一个地图类。假设您目前没有任何调用者需要知道地图中的项目数，并且您当前的实现有一个 size 变量，您可以轻松返回。您可以添加一个返回地图大小的getSize 函数。它在逻辑上是地图类公开的功能的一部分。因此，即使当前调用者不需要知道大小，人们也可以争辩说它应该是公开的。

但是，未来的实现完全有可能希望摆脱size 变量。也许增加和减少大小的开销很大，并且实现更改为不需要知道大小。如果你暴露了getSize 函数并且它被调用了，你要么必须继续跟踪大小，即使你不需要它，要么使函数非常昂贵，不得不实际计算大小。

假设很多代码需要知道表是否为空，您为此提供了isEmpty 函数。经验表明，如果您还提供getCount 函数，人们会使用getCount() == 0 而不是isEmpty。这在今天可能没有任何区别，但它可能会限制您未来的实施选择，以使 getCount 与 isEmpty 一样便宜。

如果可能，我强烈建议您将其公开，前提是您可以轻松想象该类的正常用户将受益于访问该功能，并且它构成了该类提供的功能的逻辑部分。否则，无论如何，您以后都可以轻松添加它。所以不要过分强调它。这主要是一个风格问题，混合着试图预测未来。

Answer 5

面向对象开发的基本原则；一个类的实例应该只公开它的客户需要访问的内容。请参阅link 并搜索“封装”。