我们什么时候应该使用公共的，什么时候应该使用私有的
本文关键字：什么时候 我们 | 更新日期: 2023-09-27 17:55:29
当我们实现目前未被团队解决方案中的其他类使用的方法时，访问修饰符应该是公共还是私有？我相信"公共成员说这个成员表示这个对象提供的关键、记录的功能。我们只制作私有的"实现细节"方法，并且所有将来有用的方法都应该公开，即使现在在其他类中没有我们的方法的使用者。但我的对手说，这种方法应该是私人的。你怎么看？
添加：让我们更具体一点。例如，有一个类 SqlHelper。其中有用于与SQL服务器进行操作的有用功能。特别是使用与SQL服务器的连接。但不仅在那个班级。
例如，我需要实现公共静态 HandleSqlExeption 方法（现在仅适用于类 SqlHelper），它将处理 SqlExeptions。但是我希望在异常处理中有SQL连接操作的所有类都将使用此方法（而不是简单的方法，例如： catch （Exception） { MsgBox {"SqlError"};就像现在某处发生的那样。所以我认为公共访问修饰符会告诉其他同事他们可以使用这种方法。私人将隐藏该方法。如果有人要求使用这种方法，我将需要 ti 更改代码和 rebuid 汇编。为什么？只有负面因素。
通常，应使用尽可能少的允许访问修饰符进行编码。
- 如果未在类外部使用该方法，请将其设为
private。 - 如果需要通过继承类型使用该方法，请将其设为
protected。 - 如果该方法仅在程序集内使用，请将其设为
internal。 - 仅当该方法要在程序集外部使用时，才应将其
public。
这有助于隐藏信息，并允许您随意更改实现。
我听说这是在保护你的私人。
在 API 设计方面，您应该有一个完整的 API，将所有
逻辑功能公开为public - 这就是为什么您应该在 .NET 中使用接口进行 API 设计，因为所有接口成员都必须public。在实现类时，对不属于接口的任何成员使用上述经验法则 - 除非就其使用者而言，它们构成了接口的逻辑部分。
因此，如果您现在正在使用Read方法，则应具有具有相同可访问性的互补Write方法。这是一个很好的设计（对称和预期），但是如果公共方法使用私有方法，则读取或写入方式应该隐藏在私有方法后面。
根据名称描述的方法的性质使用公共和私有。
public该方法何时可以公开给其他对象，并且
private其他对象不应访问该方法的时间。
如果对象需要更安全，请使用private访问说明符。您还应该了解protected访问说明符的不同之处在于，这些方法只能由继承它们的对象访问。
如果一个类有一些东西要暴露给外界，那么把它公开，否则是私有的。 它取决于类的功能和目的，而不是当前或将来的需求。
判断调用。一般来说，如果它在逻辑上是类呈现的接口的一部分，以获取它提供的功能，那么即使它没有当前用户，它也应该是公共的。这将减少每次您想将类用于与您已经使用它的大致相同的事情时需要修改该类的可能性。
但是，这是有代价的。公开的每个函数都是你承诺提供的功能。如果将来您决定将其从公共接口中删除，则可能会中断调用方。
例如，考虑一个地图类。 假设您当前没有任何调用方需要知道映射中的项数，并且您当前的实现有一个可以轻松返回的size变量。您可以添加一个返回地图大小的getSize函数。从逻辑上讲，它是映射类公开的函数的一部分。因此，人们可以争辩说，即使当前没有呼叫者需要知道大小，它也应该是公开的。
但是，将来的实现完全有可能希望摆脱size变量。也许递增和递减大小的开销很大，并且实现更改为不需要知道大小。如果您公开getSize函数并调用了它，则即使不需要它，您也必须继续跟踪大小，或者使函数非常昂贵，必须实际计算大小。
假设很多代码需要知道表是否为空，并且您为此目的提供了一个isEmpty函数。经验表明，如果你也提供一个getCount功能，人们会做getCount() == 0而不是isEmpty。这在今天可能没有任何区别，但它可能会限制您未来的实施选择，以保持getCount像isEmpty一样便宜。
在可能的情况下，如果您可以轻松想象该类的未损坏用户将从访问该功能中受益，并且它构成了该类提供的功能的逻辑部分，我强烈建议将其公开。否则，您以后可以轻松地添加它。所以不要太紧张。这在很大程度上是一个风格问题，与试图预测未来混合在一起。
面向对象开发的基本原则;类的实例应该只公开它的客户端需要访问的内容。请参阅链接并搜索"封装"。