问题标签 [aggregation]

为什么更喜欢组合而不是继承？每种方法都有哪些取舍？什么时候应该选择继承而不是组合？

关于如何在面向对象系统中最好地扩展、增强和重用代码，有两种思想流派：

1. 继承：通过创建子类来扩展类的功能。覆盖子类中的超类成员以提供新功能。当超类想要一个特定的接口但不知道它的实现时，使方法抽象/虚拟以强制子类“填充空白”。

2. 聚合：通过获取其他类并将它们组合成一个新类来创建新功能。为这个新类附加一个通用接口，以实现与其他代码的互操作性。

每种方法的好处、成本和后果是什么？还有其他选择吗？

我看到这个辩论经常出现，但我认为 Stack Overflow 上还没有被问到（尽管有一些相关的讨论）。令人惊讶的是，它缺乏良好的谷歌搜索结果。

我正在尝试在 MySQL 中完成以下操作（请参阅pseudo代码）

有没有办法在 WHERE 子句中不使用 (SELECT...) 来做到这一点，因为这似乎是一种资源浪费。

我必须在 Linux 上检测端口聚合配置。

假设 ifcfg-* 文件未更新（仅使用 ifenslave 完成配置），我如何了解哪个 eth？设备是哪个债券的奴隶？设备？

我有一张叫做画廊的桌子。对于画廊中的每一行，表格图片中有几行。一张图片属于一个画廊。然后是桌票。每一行都是对某个画廊的赞成或反对。这是（简化的）结构：

现在我想要一个查询给我以下信息：所有画廊都有自己的数据字段和连接到画廊的图片数量和投票的汇总值。

这是我的查询，但由于多次加入，聚合值不是正确的。（至少当图片或选票超过一排时。）

因为我注意到这COUNT( DISTINCT picture_id )给了我正确数量的图片，所以我尝试了这个：

它在这个例子中有效，但是如果一个查询中有更多的连接呢？

只是想知道是否有更好或更“优雅”的方式可以解决这个问题。另外我想知道我的解决方案是特定于 MySQL 还是标准 SQL？

我想知道每个人在他们的系统上使用什么来进行日志记录、日志管理和日志聚合。

我在一家公司工作，该公司的所有应用程序都使用 .NET，并且所有系统都是基于 Windows 的。目前，每个应用程序都负责自己的日志记录和失败通知（例如，如果应用程序 A 失败，它将向管理员发送自己的“求助电话”）。

虽然这种当前的做法有效，但它有点笨拙且难以管理。我一直在尝试找到一些使这项工作更好的选择，并且我提出了以下建议：

• log4net 和电锯（啊，如果可以的话）。
• 通过 log4net 或其他框架登录到中央数据库并滚动我们自己的管理工具。
• 记录到 Windows 事件日志并使用 MOM 或 System Center Operations Manager 来聚合和管理每个服务器及其应用程序。
• 一种手动解决方案，可将所有日志文件集中到一个点并在它们之间发挥一些作用。

本质上，我们所追求的是可以将日志条目全部拉到一起并允许在它们之间运行一些分析的东西，再加上使用一种基于事件的系统，例如，当有 30 多个警告时发送警告电子邮件应用程序在最后x几分钟内的级别日志。

那么有什么我错过的，或者其他人可以建议的吗？

我正在开发一个市场网站，导师和学生可以在其中找到彼此。我正在建立一个在线支付系统（很像 elance 或 guru.com），导师可以在其中获得报酬，我们可以从中分得一杯羹。

几个问题：

1. 阻止来自某些国家（如尼日利亚）的 IP 地址的最佳方法是什么？（注意，我使用的是 Ruby on Rails，因此任何特定于此的建议都会更好，但如果不是也可以。）

2. 除了阻止某些 IP，我还可以使用哪些其他技术？（我已经在做 AVS 和正常的网关检查）。

3. 我需要检查哪些常见的骗局？

例如，我能想到的一个人使用该系统为自己付款，他们收到资金作为付款（减去​​我们的费用），然后对信用卡进行退款。

我想这些类似于 Paypal 或 Google Checkout 等网站（有些人称这些聚合网站）所面临的问题，因为它们收取一小部分费用 - 所以如果失去原始资金来源，那将是巨大的损失（很多倍的与正常的高利润产品不同，所涉及的利润）。

几个附加说明：

1. 我的用户帐户已经需要电子邮件验证 - 这是最低要求，我正在寻找超出此范围的内容
2. 直接存款有 3-5 天的等待期 - 这是银行要求的 - 但仍然没有回答如何在这 3-5 天内确定是否是欺诈以便可以取消的问题
3. 我宁愿避免一种既惩罚好人又惩罚坏人的解决方案-例如收取注册费用或让他们将资金留在那里直到要求提款（例如Paypal）

我注意到许多关于 COM 的书籍等都指出，在 COM 聚合中实现一个可用作内部对象的对象相对容易。但是，除非我遗漏了什么，否则聚合似乎只能在极其有限的场景中成功，因此只有在明确识别出这种场景时才应提供对它的支持。

困扰我的部分如下。COM 聚合将内部对象的身份与外部对象的身份相结合。外部对象的实现者选择内部对象接口的子集，并将这些接口的请求转发给内部对象。内部对象将所有接口请求转发给外部对象。现在假设内部对象，作为其实现的一部分，构造子 COM 对象。大概一个接口指针被传递给该 COM 对象，以便它可以与其父对象通信。内部对象对它实现的接口有一些想法。然而，外部对象可能选择不转发其中一些接口。实际上，文档指出外部对象不应盲目转发接口。这似乎意味着内部对象通常不能将接口指针传递给其他 COM 对象，除非特别要求外部对象将所有这些接口转发给内部对象。这不限于子对象方案。实际上，内部对象实现传递接口指针的任何地方似乎都可能受到影响。

因此，聚合似乎不是通用目的，因为在内部对象必须与其他 COM 对象通信的情况下，它对外部对象提出了严格的要求，即必须最少转发哪些接口，并且不能添加更多接口。此列表在内部对象的未来版本中不会破坏与不转发这些接口的现有外部对象的兼容性。

这是对事物实际情况的正确（并且很少记录）描述还是故事还有更多内容？

如果你有一个 A 类是 B 类和 C 类的集合，那么它对 A 更好吗？

• 存储 B 和 C 的 ID
• 为 B 和 C 加载和存储整个对象（编辑，通过引用对象 B/C 存储，即实例化对象 B 和 C，而不是为 B 和 C 存储 id。
• 存储 ID 并提供提取方法 B 和 C 的方法

我假设这取决于性能要求和其他要求，但我只是在寻找任何一般指导方针或想法。

关联、聚合和组合之间有什么区别？请在执行方面进行说明。