问题标签 [encapsulation]

随着项目规模的扩大，您知道哪些方法、实践和约定可以模块化 C 代码？

我想知道其中哪一个会被认为是最干净或最好用的，为什么。

其中一个公开乘客列表，让用户添加和删除等。另一个隐藏列表，只让用户枚举它们并使用特殊方法添加。

示例 1

示例 2

我要说的第一类更好地封装。在这种确切的情况下，这可能是更好的方法（因为您可能应该确保它在公共汽车上留下了空间等）。但我想在某些情况下，二等舱也可能有用？就像班级并不真正关心该列表会发生什么，只要它有一个。你怎么看？

尝试在此处的项目上运行运行代码分析，并收到许多警告，内容如下：

CA1002：Microsoft.Design：将“ SomeClass.SomeProtectedOrPublicProperty ”中的“List< SomeType >”更改为使用 Collection、ReadOnlyCollection 或 KeyedCollection

为什么我应该使用Collection<T>而不是List<T>？当我查看 msdn 文档时，它们似乎几乎相等。在阅读了警告的错误帮助后，我发现

System.Collections.Generic.List(T)_是为性能而非继承而设计的通用集合，因此不包含任何虚拟成员。

但这究竟意味着什么？而我应该怎么做呢？

我应该继续List<T>在内部使用，然后在属性中返回 anew Collection<T>(someList)吗？还是我应该开始使用Collection<T>而不是List<T>？

因此，我的应用程序公开了这个公共 API，允许客户编写插件。为了这个示例，假设它是一个相当简单的键值对系统，例如：

现在假设在内部，Key有一些不应该公开的属性——比如数据库 ID。我目前正在做的是这样的：

这似乎不太理想。有什么方法可以重新安排职责以避免演员表并仍然保持内部/外部封装？

请注意，在现实世界中它比这要复杂一些。等价物附加了Key相当多的元数据，除了获得一个简单的值之外，人们可能还想做很多事情，所以仅仅公开，比如说，类似Map.Entry的对象并不一定能解决问题。

我唯一能想到的就是将内部和外部键完全分开，并保留一个Map<Key, InternalKey>. 但在那种情况下，我必须复制违反 DRY 的元数据，或者让外部Key委托到InternalKey，在这种情况下Map违反 DRY。

谁能想到更聪明的方法？

我猜我们大多数人都必须在某个时候处理这​​个问题，所以我想我会问这个问题。

当你的 BLL 中有很多集合并且你发现你一遍又一遍地编写相同的旧内联（匿名）谓词时，显然有一个封装的情况，但实现这一目标的最佳方法是什么？

我目前正在从事的项目采用古老的、回答所有的、静态类方法（例如 User 类和静态 UserPredicates 类），但这似乎有点笨拙，有点逃避。

我主要在 C# 中工作，所以保持这种情况最有帮助，但我认为这是一个足够通用的问题，足以保证听到其他语言。

此外，我预计随着 LINQ 和 Lambdas 的出现如何实现这一点会有所不同，所以我很想知道如何在 .Net2.0 和 3.0/3.5 样式中实现这一点。

提前致谢。

我必须处理大约 20 个 POST 参数，我不知道在哪里做。

我可以将每个定义为模型上方法的参数，并在调用方法时从控制器传递它们。由于参数的数量，这将导致相当多的工作并使函数调用的可读性降低。

或者我可以调用模型上的方法，直接访问参数。

将参数作为参数传递可以让我更好地控制函数访问哪些参数，并且文档将更加不言自明。但是，如果稍后添加新参数，则必须将它们添加到方法调用的末尾，以免破坏每个现有调用。我想如果它发生几次，这会变得相当混乱，因为这些论点无法在逻辑上进行分组。

如果我访问模型中的参数，则无需将任何参数从控制器传递到模型，从而使方法调用更简洁。但我无法控制访问的参数，因为可以轻松且不受限制地添加或删除它们。这将需要其他开发人员更严格的纪律，我不喜欢依赖这一点，因为迟早有人会“快速（添加|更改|修复）这个真正的快速”。

我不确定该走哪条路。我倾向于只在模型中完成所有操作，因为这样可以更快地编写，似乎更易于维护（没有参数混乱）并且在概念上更适合我对模型的看法。另一方面，我不确定我对模型的看法是否正确，如果我依赖其他开发人员在每次更改后始终更新文档，它是否会以混乱告终。

所以我该怎么做？

我想知道是否可以封装一个类的方法，然后在消费类中公开它们。例如（JFTR，我知道这段代码是错误的）

最终，我希望能够制作不能在单个控制类的上下文之外直接引用的组件。

很多人都知道这篇文章：关于 getter 和 setter 的更多信息。我认为它在描绘 getter/setter 的邪恶方面方面做得很有说服力。我还通过尝试将现有项目（未完成）转换为没有 getter/setter 的代码来测试它。有效。代码可读性大大提高，代码更少，我什至设法摆脱了我最初认为确实必要的 getter/setter。除了一处。

让模型进入视图部分是我认为这种方法没有抓住重点的地方。在文章中，作者使用构建器来导出模型。问题是：对于放入构建器的内容的控制与使用 getter 获得的控制一样多。是的，它隐藏了实现，它在模型中的表示方式。但是吸气剂不会从模型中得到与放入其中的非常不同的东西。如果您创建一个通过构造函数传递“5”的 Money 对象，money.getAmount() 将不会返回转换为其他货币或包含一个元素“5”的数组。

你设置你得到什么。通过视图我们设置值，以及当我们从一个应该保存我们最初设置的对象中请求（获取）它们时我们期望的那些值。导出这些的构建器只是期望相同。

这个问题有点长。但我想在我的观点上受到挑战。将模型数据传输到视图层时，getter 和 setter 是否邪恶？

有很多人认为 getter/setter 一点都不邪恶。这也不是我想听到的辩护，因为我认为他们在其他地方确实是邪恶的，而不是我提到的那些地方。

关于封装的维基百科文章指出：

“封装还通过防止用户将组件的内部数据设置为无效或不一致的状态来保护组件的完整性”

我在一个论坛上开始讨论封装，在其中我问你是否应该总是在 setter 和/或 getter 中克隆对象以保留上述封装规则。我认为，如果您想确保主对象内部的对象不会被主对象外部篡改，您应该始终克隆它。

一位讨论者认为，在这个问题上，您应该区分聚合和组合。基本上我认为他的意思是：

• 如果要返回一个作为合成一部分的对象（例如，矩形的点），请克隆它。
• 如果要返回一个属于聚合的对象（例如，作为 UserManager 的一部分的用户），只需在不破坏引用的情况下返回它。

这对我来说也很有意义。但现在我有点困惑。并想听听您对此事的看法。

严格来说，封装总是要求克隆吗？

PS.：我用 PHP 编程，资源管理可能更相关，因为它是一种脚本语言。

我正在讨论正确的 OO 设计，以使用来自 java 类的另一个对象的功能（方法），同时尽可能地保持两个对象的解耦。

例如，在我的类中的某个时刻，为了实现我的逻辑，我需要调用一个属于另一个对象的方法，比如一个辅助类。这个帮助类不需要与我的原始类有任何关系，它只是有一个特定的方法，它对我的​​类可见并且可供我的类使用。

实现逻辑后，就不再需要辅助方法（或辅助对象）了。

显然，为了使用它的方法，我需要一个对这个帮助对象的引用。但是为了强制封装，我不应该在我的原始类中声明一个实例变量来引用这个助手对象吗？这个推理正确吗？此外，助手类不知道任何可能使用它的客户端类。

在这种情况下，局部变量会更合适吗？在将使用其功能的方法中声明并实例化辅助对象？在我的原始类中声明和实例化这样一个辅助对象的最佳位置在哪里？

我想知道是否有一个高级示例，或者是否在 OO 文章中对此进行了更详细的解释。我将不胜感激以上任何以封装为重点的输入或提示。