问题标签 [encapsulation]

在设计泛型库的公共 API 时，应该公开多少内部使用的低级内容？一方面，用户不应过于依赖实现细节，过多的低级函数/类可能会使 API 混乱。因此，下意识的反应可能是“无”。另一方面，一些低级功能可能对人们有用，并且公开更多功能可以防止抽象反转（在高级构造之上重新实现低级构造）。

此外，暴露更多的低级细节可以提供性能捷径。例如，假设您有一个查找数组中位数的函数。最不意外的原则是你应该复制数组，这样你的 API 的用户就不必关心它的实现涉及重新排序元素的副作用。在这种情况下，您是否应该注意 medium() 会消耗内存分配并提供另一个绕过分配但会任意重新排序用户输入的函数？

对于要公开多少此类细节，有哪些一般准则？

封装对象和管理其生命周期的最佳方法是什么？示例：我有一个类A，它包含一个B类型的对象并单独负责它。

解决方案 1，克隆b对象以确保只有A能够清理它。

解决方案2，直接使用传递的对象，我们在这里冒着潜在的双重释放的风险。

在我的实际情况下，解决方案＃2 最适合。但是我想知道这是否被认为是糟糕的代码，因为有人可能不知道A的行为，即使它已记录在案。我可以想到这些场景：

或者，

如果我正确记录了 A 的行为，我可以忽略这些问题吗？声明责任并让其他人阅读文档就足够了吗？这是如何在您的代码库中管理的？

我意识到这是一个非常基本的问题，但它一直困扰着我。据我了解，如果您在 Java 中声明一个私有字段，那么它在该类之外是不可见的。如果它受到保护，那么它可用于继承的类和同一包中的任何东西（如果其中任何一个定义不正确，请纠正我）。

这是否意味着不能声明一个只能被继承类访问的​​字段，而不是同一包中的其他非继承类？

我很欣赏有办法解决这个问题，但是有没有你想要这种行为的情况？

显然，上述问题适用于方法和领域。

非常感谢。

更新： 09/02/2009 - 修订问题，提供更好的示例，增加赏金。

嗨，
我正在使用数据库和实体（域对象）之间的数据映射器模式构建一个 PHP 应用程序。我的问题是：

封装通常执行的任务的最佳方法是什么？

例如，一项常见任务是从站点映射器检索一个或多个站点实体，并从页面映射器检索它们的关联（主页）页面实体。目前，我会这样做：

现在这是一个相当微不足道的例子，但实际上它变得更加复杂，因为每个站点也有一个关联的语言环境，并且页面实际上有多个修订版（尽管出于本任务的目的，我只对最近的一个感兴趣）。

我将需要在我的应用程序中的多个位置执行此操作（获取站点和关联的主页、区域设置等），并且我想不出封装此任务的最佳方式/位置，所以我不会必须到处重复。理想情况下，我希望得到这样的结果：

生成的站点实体已创建关联实体并可供使用。

保存这些对象时也会出现同样的问题。假设我有一个站点实体和关联的主页实体，并且它们都已被修改，我必须执行以下操作：

同样，微不足道，但这个例子被简化了。重复代码仍然适用。

在我看来，拥有某种可以处理的中心对象是有意义的：

• 检索一个（或多个）站点和所有必要的关联实体
• 使用新的关联实体创建新的站点实体
• 获取一个（或多个站点）并保存它和所有关联实体（如果它们已更改）

所以回到我的问题，这个对象应该是什么？

• 现有的映射器对象？
• 基于存储库模式的东西？*
• 基于工作模式的东西？*
• 还有什么？

*正如您可能猜到的那样，我不完全理解其中任何一个。

有没有解决这个问题的标准方法，有人可以提供他们如何实现它的简短描述吗？我不是在寻找任何人来提供一个完全有效的实现，只是理论。

谢谢，
杰克

DUPE：实践中的私人与公共成员（封装有多重要？）

在用 Java 编写程序的过程中，我已经抽象出一些库，我可以看到它们在未来的项目中可能会用到。

为什么我要为这些方法中的任何一种设置受限访问（私有/受保护）而烦恼？

看来这只会让我未来的生活变得更加复杂。如果我在所有东西上都使用 public，我将永远不需要担心我是否可以从其他类中调用某些东西。我从来没有在我的任何代码中看到过这样一个案例，我可以使用除 public 之外的任何东西。

在所有事情上都使用“公共”是错误的吗？我会被 Java 众神击倒吗？

通过将功能放入函数中，仅此一项是否构成封装的示例，还是您需要使用对象进行封装？

我试图理解封装的概念。我的想法是，如果我从这样的事情出发：

n = n + 1

它作为一大段代码的一部分在野外执行，然后我把它放在一个函数中，比如这个函数，然后我把这个添加逻辑封装在一个方法中：

或者，如果我向外界隐藏 addOne 的详细信息，它是否只是封装 - 比如它是一个对象方法并且我使用私有/受保护的访问修饰符？

我在 C++ 中有以下类层次结构：

我想保证实现级别的类不提供它们自己的应用实现，并且它们只实现派生专业。有没有办法保证继承自 Derived 的类不会实现 apply，从而使用 Derived::apply 实现？我的理解是，在 C++ 中，基类中的虚拟方法在继承层次结构中一直是虚拟的，但是如果 C++ 中有任何技巧可以完成，我很想听听它们。

我总是对 C++ 允许的事情感到惊讶，所以我认为值得一问。:)

我有一堂课Server，它与 IRC 的服务器连接对话。它拥有一个已知Users 的列表，并根据需要创建它们。

我有两个涉及User课程的问题：

1. 任何人都可以创建User. 我只希望Server班级能够做到这一点。
2. 如果用户（事物User描述）更改了他/她的姓名（或其他信息，如加入的频道），则Server该类可以自行更改。但是，其他类也可以！我想禁止其他类接触此信息（使其只读）。

我该如何解决这两个问题？在 C++ 中，它可以通过使用friend关键字并使 ctor 和setName（等）私有来解决。

是否有一个 C# 关键字可以允许指定类访问某个方法？这将解决我的问题。

我的应用程序中有一个数据类。我的应用程序永远不会被用作公共 API，我将是唯一在我的项目中开发代码的人。

我正在努力节省每一盎司的处理器和内存容量。

让我的数据类中的数据成员具有公共/受保护/默认保护以便我不必使用吸气剂是一个坏主意吗？使用吸气剂将需要更多的内存和堆栈的创建等等......我认为这是没有必要的。我可以看到使用 getter 的唯一原因是为了保护/隐私，但如果我是唯一的编码人员并且没有其他人会使用我的 API，那么不使用 getter 是不是一个坏主意？

如果这很愚蠢，请告诉我。

在我以前的 C++ 工作中，我们总是非常小心地封装成员变量，并且仅在绝对必要时才将它们公开为属性。我们会有非常具体的构造函数来确保您在使用对象之前完全构造它。

这些天来，使用 ORM 框架、依赖注入、序列化等，看起来你最好只依赖默认构造函数并在属性中公开你的类的所有内容，这样你就可以注入东西，或者构建和填充对象更动态。

在 C# 中，对象初始化器更进一步，它使您能够基本上定义自己的构造函数。（我知道对象初始化器并不是真正的自定义构造器，但我希望你明白我的意思。）

这个方向有什么普遍的担忧吗？为了方便起见，封装似乎开始变得不那么重要了。

编辑：我知道您仍然可以仔细封装成员，但我只是觉得当您尝试创建一些类时，您要么必须坐下来仔细考虑如何封装每个成员，要么将其公开为属性，并担心它以后如何初始化。现在似乎最简单的方法是将事物公开为属性，而不是那么小心。也许我完全错了，但这只是我的经验，尤其是新的 C# 语言功能。