问题标签 [composition]

1. 使用 MEF，我编写我的 DLL

2. 我使用我的 DLL

3. 我在没有这个 DLL 的情况下重组

4. 我想删除它 // => 它不起作用

如何卸载 dll 以便在未组合此 dll 的 MEF 重组后将其删除？

我正在研究 MEF 作为我们现有 .NET 应用程序中插件解析的解决方案。

在我能找到的所有示例中，主应用程序都会创建一个 CompositionContainer 实例并调用 container.ComposeParts(this)。

问题是，我的应用程序并非完全建立在 MEF 之上，因此对象图中存在一个没有 MEF 组件的漏洞。所以我的对象层次结构可能如下所示：

应用程序（MEF 容器）-> ObjectB（无 MEF）-> ObjectA（需要 MEF 导入）

在这个对象层次结构中，我不可能在应用程序上调用 container.ComposeParts(this) 并期望应用程序创建 ObjectB 并满足 ObjectA 的 Imports。

全局公开 CompositionContainer 是否是一种好习惯，以便我可以在应用程序启动之后的时间组合 ObjectA，或者我是否必须重组整个应用程序以支持线性 MEF 对象图？

我已经提取了继承和组合之间的以下差异。我想知道后端对象创建延迟是什么意思？请找出下面的区别。

组合允许您延迟后端对象的创建，直到（除非）需要它们，以及在前端对象的整个生命周期内动态更改后端对象。通过继承，您可以在创建子类后立即在子类对象图像中获得超类的图像，并且在子类的整个生命周期中它仍然是子类对象的一部分

我正在尝试在类中拆分我的代码。但有一个问题真正困扰着我。当我为函数创建一个类时，我给出了自己的阶段。像这样

在课堂上我用这个

如您所见，我现在可以使用 stage.var1 = "hi" 调用舞台的变量，但是当我需要多次调整该变量时，它会变得非常混乱...

有一种方法可以告诉我，当我调用 var1 时，他知道我的意思是 stage.var1，而无需调用 stage。它的：

然后使用

但这也很不方便有更好的方法吗？

我有一个类，我很早就在我的 vb.net 编程经验中编写了它，它继承自另一个它确实应该组成的类。基类是一个相对通用的基于字典的嵌套集合；让我们将后代类称为“汽车”。

现在有很多代码可以做类似'MyCar!Color.st = "Red"'的事情（我使用通用集合而不是真实属性来促进与用VB6编写的代码进行数据交换，也便于比较汽车；给定三辆车 X、Y、Z，我可以例如检测 X 和 Y 之间的任何变化并将这些变化应用于 Z）。

有什么好方法可以重构代码以使用组合而不是继承？“汽车”对象应该包装哪些属性/方法，哪些应该通过数据对象属性访问？是否应该在汽车和集合对象之间定义扩大转换？进行此类重构时是否有任何问题？

例如，如果我有以下要求： 1. 狗是动物 2. 动物园有动物 我是否还需要第二个菱形连接器（较低的连接器），如下所示：

我知道这个问题之前已经讨论过，但似乎总是假设继承至少有时比组合更可取。我想挑战这个假设，希望获得一些理解。

我的问题是这样的：既然你可以用对象组合来完成任何你可以用经典继承来完成的事情，而且因为经典继承经常被滥用[1] ，而且由于对象组合让你可以灵活地更改委托对象运行时，为什么你会使用经典传承？

我可以理解为什么您会建议在 Java 和 C++ 等不提供方便的委派语法的语言中使用继承。在这些语言中，只要不明显不正确，您就可以通过使用继承来节省大量输入。但是其他语言，如 Objective C 和 Ruby，提供了经典的继承和非常方便的委派语法。据我所知，Go 编程语言是唯一一种认为经典继承比它的价值更麻烦并且只支持代码重用的委托的语言。

陈述我的问题的另一种方式是：即使您知道经典继承对于实现某个模型并没有错误，是否有足够的理由使用它而不是组合？

[1] 许多人使用经典继承来实现多态性，而不是让他们的类实现接口。继承的目的是代码重用，而不是多态。此外，有些人使用继承来模拟他们对“is-a”关系的直观理解，这通常是有问题的。

更新

当我谈论继承时，我只是想澄清一下我的意思：

我说的是类继承自部分或完全实现的基类的那种继承。我不是在谈论从一个纯粹的抽象基类继承，这相当于实现一个接口，我郑重声明并不反对。

更新 2

我知道继承是在 C++ 中实现多态性的唯一方法。在这种情况下，很明显为什么你必须使用它。所以我的问题仅限于提供不同方法来实现多态性（分别为接口和鸭子类型）的 Java 或 Ruby 等语言。

我对 Delphi 2009/2010 对 Windows 中 Aero Theme Glass 功能的支持、DoubleBuffered 的确切含义以及它与 Aero glass 的关系感到困惑。我发现 DoubleBuffered 不仅是 VCL 中的一个属性，它也可以在.net WinForms中找到。最初我想知道它是否设置了公共控件库使用的某种窗口样式位，或者什么。为什么使用它，何时使用？

[更新：我应该声明我知道什么是“双缓冲”，作为一种减少闪烁的通用技术，我想知道的是，为什么它与 Windows Vista 中 Aero Glass 窗格上的渲染控件有任何关系/ Windows 7，特别是为什么所有事物的 BUTTON 都需要将双缓冲设置为 true，才能在玻璃上工作？下面链接的博客文章似乎信息量最大。]

尤其是对DoubleBuffered属性很困惑，想知道它为什么存在，它的玻璃支架和窗体、控件中的双缓冲属性是什么关系。当您阅读像这样的 C++ 文章时，您会发现没有提到双缓冲。

[更新2：以下内容包含一些事实错误，并已进行修改：]

我发现一些 C++ 开发人员谈论他们如何调用 SetLayeredWindowAttributes 以避免在经典 Win32 应用程序中打开 DWM/Aero 合成导致的“黑色变成玻璃”故障 [但是下面的博客链接告诉我这不再有效在 Windows 7 中，实际上只是在 Vista 中短暂工作，直到微软阻止它]。[Begin WRONG Idea] 我们不应该使用其他颜色，比如明亮的洋红色，然后把它变成玻璃透明色吗？[结束错误的想法]

什么时候应该设置和不设置 DoubleBuffered 的规则是什么，为什么首先将 DoubleBuffered 添加到 VCL 中？什么时候设置会出问题？（似乎远程桌面是一种情况，但这是唯一的情况吗？）当它没有设置时，我们会在按钮文本的渲染中出现故障，很可能是因为 Delphi 似乎没有更改默认的“将黑色渲染为玻璃“在 Aero DWM 中。

在我看来，Aero Glass 渲染从根本上是以一种奇怪或难以理解的方式完成的[由 Windows 本身，而不是仅包装此功能的 Delphi]，并且 2009/2010 年的许多内部 VCL 源代码StdCtrls 中的类必须做很多复杂的逻辑才能在 Aero Glass 上正确渲染东西，但它仍然有很多问题，在我看来它做错了，这可能是这个相关问题和 qc 问题的背后。 [更新 3：玻璃上的许多渲染故障，在 VCL 中，在通用控件中渲染完成错误，微软似乎并不关心修复。简而言之，Delphi VCL 代码修复无法解决这样一个事实，即古老的 Windows 通用控件库和现代 [但古怪的] Aero Glass 合成功能彼此不太喜欢，并且不能很好地协同工作。感谢 Microsoft 构建了如此高质量的技术并将其释放到世界各地。]

如果还不够有趣；为什么我们有 ParentDoubleBuffered？

[7 月 30 日更新：这个问题对我来说很有趣，因为我认为它表明，当你有一个大型的现有 VCL 框架时，使用 Windows API 来解决这个问题是一个难题。]

在 Java 世界中（更准确地说，如果您没有多重继承/混合），经验法则非常简单：“优先考虑对象组合而不是类继承”。

我想知道如果您还考虑mixins，它是否/如何改变，尤其是在scala中？
mixins 是否被认为是一种多重继承或更多类组合的方式？
是否还有“优先对象组合优于类组合”（或相反）指南？

当对象组合也可以完成这项工作时，我看到了很多例子，当人们使用（或滥用）mixin 时，我并不总是确定哪个更好。在我看来，你可以用它们实现非常相似的东西，但也有一些区别，一些例子：

• 可见性 - 使用 mixins，一切都成为公共 api 的一部分，而组合则不是这样。
• 冗长 - 在大多数情况下，mixin 不那么冗长并且更易于使用，但并非总是如此（例如，如果您还在复杂的层次结构中使用 self 类型）

我知道简短的回答是“视情况而定”，但可能有一些典型的情况是这样或那样更好。

到目前为止我可以提出的一些指导方针示例（假设我有两个特征 A 和 B，并且 A 想要使用 B 中的一些方法）：

• 如果你想用 B 中的方法扩展 A 的 API，那么 mixins，否则组合。但是，如果我正在创建的类/实例不是公共 API 的一部分，它也无济于事。
• 如果您想使用一些需要混合的模式（例如Stackable Trait Pattern），那么这是一个简单的决定。
• 如果你有循环依赖，那么带有 self 类型的 mixin 会有所帮助。（我尽量避免这种情况，但这并不总是那么容易）
• 如果您想要一些动态的运行时决定如何进行组合，然后是对象组合。

在许多情况下，mixin 似乎更容易（和/或不那么冗长），但我很确定它们也有一些陷阱，比如“上帝类”和两篇 artima 文章中描述的其他内容：第 1部分，第 2 部分（顺便说一句在我看来，大多数其他问题与 scala 无关/不那么严重）。

你有更多这样的提示吗？

我看到自己经常遇到以下问题。我有某种标记接口（为简单起见，让我们使用java.io.Serializable）和几个包装器（适配器、装饰器、代理......）。但是，当您将 Serializable 实例包装在另一个实例（不可序列化）中时，您会失去功能。可以通过 List 实现实现的 java.util.RandomAccess 也会出现同样的问题。有没有很好的 OOP 方式来处理它？