问题标签 [decoupling]

我对这种差异有一种普遍的直觉，但我无法准确指出是什么使数据库与全局状态不同。

对于“全局状态”的简单定义，数据库通常至少是应用程序全局的。可以想象，您可以拥有一个在执行过程中更改数据库的应用程序，但在一般情况下，它是全局使用的。

至于状态，我认为我不需要争论数据库包含状态的情况。

那么，是什么让数据库不同于“坏”的全局状态呢？

出现这个问题是因为我试图避免紧耦合对象需要了解其父对象。

例如，假设您正在玩一款策略游戏，而您的一个单位具有一种能力，即当它对敌方单位造成伤害时，该单位的所有者会损失 x 金币，其中 x 是造成的伤害量。

嗯，在正常情况下，一个单位不应该知道它的所有者是谁。所有者是控制单元的人，因此所有者只需向单元发出命令，它就会做它的事情。

但是，由于外部因素，需要找出单位的所有者是谁。在这种情况下，攻击单位知道它正在攻击的单位，这很好。但是现在除了知道它正在攻击的单位之外，它还必须进一步知道它的所有者才能使所有者损失 5 金币。

我已经偏离了最初的问题，超出了我的预期，但是如果游戏的状态存储在关系数据库中，那么查询目标的所有者将是微不足道的，而单位不需要直接知道他们的所有者是谁。如果这样的数据库是一个对象，我会称该数据库为上帝对象，因为它知道所有事物的整个状态，而且是可变的。

那么，是什么让数据库不同于全局状态呢？

我正在尝试将策略模式应用于特定情况，但是在如何避免将每个具体策略耦合到为其提供数据的上下文对象时遇到了问题。下面是一个模式的简化案例，它以几种不同的方式出现，但应该以类似的方式处理。

我们有一个对象Acquisition，它提供与特定时间框架相关的数据——基本上是一堆使用不同硬件收集的外部数据。由于它包含的数据量，它已经太大了，所以我不想给它任何进一步的责任。我们现在需要获取其中的一些数据，并根据一些配置向硬件发送相应的电压。

因此，想象一下以下（非常简化的）类：

现在，每个具体的策略类都必须耦合到我的 Acquisition 类，这也是最有可能被修改的类之一，因为它是我们应用程序的核心。这仍然是对旧设计的改进，旧设计是类中的一个巨大的switch语句Acquisition。每种类型的数据可能有不同的转换方法（虽然Battery是简单的传递，但其他的根本不是那么简单），所以我觉得策略模式或类似的应该是要走的路。

我还会注意到，在最终实现中，IAnalogOutputter将是一个抽象类而不是一个接口。这些类将位于用户可配置的列表中并序列化为 XML 文件。该列表必须在运行时可编辑并被记住，因此 Serializable 必须是我们最终解决方案的一部分。万一它有所作为。

如何确保每个实现类都获得工作所需的数据，而不将其绑定到我最重要的类之一？还是我以完全错误的方式处理这类问题？

我们正在制作一个相当大的 Swing 应用程序，它必须实现 MVC 模式。该应用程序当前如下所示：

有不少观点。它们以分层方式创建，其中一个主视图包含（并创建）多个视图，这些视图都包含它们自己的一组子视图等。这些视图中的每一个都通过调用模型独立于其他视图从模型中检索信息必要时使用静态方法。

还有相当多的控制器彼此完全分开。每个控制器都属于一个视图。每个视图创建自己的控制器，并将控制器添加为用户输入的侦听器。控制器从视图接收事件，然后通过模型静态方法修改模型。当视图调度不影响模型但仅影响视图的事件时，视图会自己处理这些事件 - 无需通知控制器有关事件。也就是说，控制器完全不知道视图，控制器的目的只是处理模型的操作。| 编辑：控制器当前是其视图的附件；它们只包含事件处理的逻辑。也就是说，控制器本身不是组件，也不包含组件。它们的实现方式与以下示例相同：MVC 示例|

应用程序中的模型非常被动，甚至没有监听器（它代表一个数据库）。它接收来自控制器的更新。

在这个例子中，视图拥有控制器。如果控制器拥有并创建视图，并且让视图不知道控制器，而不是相反，在一般情况下会更好吗？在那种情况下，为什么？这将如何设计？如果没有，是否有更好的设计让控制器仍然不知道视图？或者，最好的设计都不是它们吗？

编辑：

如原始 MVC 定义中所述：

“视图负责建立这种相互通信......”这一行似乎表明视图创建了控制器，或者至少具有对控制器的初始引用，反之亦然。

所以这至少是一种可能的方法（它是一个有效的 MVC 模式），但主要问题仍然存在；哪个更好，最好的设计会是什么样子？尤其是在处理与其各自视图密切相关的许多控制器时？

编辑：另一个引用控制器的视图示例：Oracles 示例

我想看看一些非常好的 iOS 应用程序，看看它们是如何组合在一起的。我指定了“完整”，因为我对当前目的更感兴趣的是策略而不是战术（但希望代码在战术上也能做得很好）。“完整”不一定意味着“大”。

我自己最初的优先事项是整体设计是可可惯用的（即充分利用 Apple 为我们提供的东西），并重点强调在相关设计约束内尽可能解耦的类。但我会对任何能够充分说明特定公开可用代码库值得仔细检查的答案感兴趣。

编辑：虽然我的主要关注点是应用程序，但图书馆的指导性示例也可能很有趣。

为了在 c# 中创建干净的解耦代码，我希望获得一些关于使用动态参数构造对象的反馈。通常我相信你会创建一个接口并将接口用作合同，但是你必须为你所有的类创建接口，我认为这有点恶心......

所以，我的问题是做这样的事情有什么好处和坏处：

对比

我正在实现一个接收不同请求的 SOAP-Webservice。我的 Manager 类是否应该在将 Request 对象委托给实现类之前将其转换为内部表示？

我认为这将是一个关于解耦的好主意。但是这样做我必须创建每个 RequestObject 类的副本并将其命名为 InternalRequestObject，它存储与原始请求相同的数据。

这有意义吗？

假设我有一个名为 Component 的抽象基类，它是 GUI 组件层次结构的根。在这种情况下，我们可能有两个子类，Button 和 Label，它们也是抽象类，并且作为它们各自的具体类层次结构的根而存在。

从 Button 继承的具体类可能包括 RoundButton 和 SquareButton。

从 Label 继承的具体类可能包括 TextLabel 和 PictureLabel。

最后，假设有一个聚合 Container 类，其中包含 Component 对象的集合。

问题是我有指向组件对象的指针，但我需要将它们标识为按钮或标签。例如，如果我想指定所有 Button 的内部文本应该有一个更大的字体，我可以遍历 Container 中的所有 Component 对象，并以某种方式确定哪些是按钮，并调用一些特定于按钮的方法。

这些组件“家族”标识自己的一种方法是使用字符串。

这是松耦合的，因为 Component 将定义这些族的任务留给了它的子级；它不需要知道存在哪些家庭。客户需要了解不同的组件系列，但如果它试图针对某个特定的组件系列进行某些操作，那么这是无法避免的。

但是，假设我们有非常高的性能要求并且我们希望避免比较字符串。避免使这个函数成为虚拟函数也很好，这样我们就可以内联它。此外，如果 Component 的每个子类都需要声明一个全局常量，那么以某种方式修改 Component 类以使其成为要求或使其成为不必要可能会很好。

解决此问题的一种方法是在 Component.h 中定义一个枚举器

在这种情况下 getFamilyID() 可以只返回一个 COMPONENT_FAMILY 枚举，我们基本上可以只比较整数。不幸的是，这意味着任何新的组件系列都必须在这个枚举中“注册”，这很容易，但对于其他程序员来说并不完全直观。此外，该方法仍然必须是虚拟的，除非我们创建一个非静态 COMPONENT_FAMILY 成员，我们知道该成员将具有极低的基数（不理想）。

解决这个问题的好方法是什么？就我而言，性能是关键，虽然类似于 enum 解决方案的东西似乎很容易，但我想知道我是否忽略了更好的方法。

--- 编辑 ---
我意识到我应该指出，在实际系统中，Container 等效项只能存储每个系列的 1 个组件。因此，组件实际上存储在一个映射中，例如：

应用于我这里的简单示例，这意味着容器只能包含 1 个按钮、1 个标签等。

这使得检查特定类型的组件（日志时间）是否存在变得非常容易。因此，这个问题更多是关于如何表示 COMPONENT_FAMILY，以及在我将其添加到地图时如何确定 Component 的类型。

换句话说，组件的唯一目的是被识别为添加到容器的特定功能，所有组件一起定义容器的特定行为。

所以，我不需要知道组件的类型，这已经隐含了。我专门向容器询问特定类型的组件。我需要的是一种让组件传达其类型的方法，以便可以首先对其进行映射。

我正在尝试为我的 GUI 窗口编写一个回调类。为了（希望）实现这一点，我正在使用代表。

MESSAGE_TYPE 是一个枚举。

我需要的是某种方式，当它被破坏时，通过某种持久/常量索引自动从映射中注销任何对象，而不依赖于修改类析构函数。

我的意思是，好吧，我的计划可能从一开始就有缺陷（我仍然在这些高级的东西中半盲编码），因为我指定回调以匹配某个签名，所以本质上任何使用此功能的类都必须有一些匹配它的方法，因此已经有点被迫遵守那些规则（耦合到类）。

所以我可能只是在其中引用地图。但是，仅此一项仍然需要遍历映射中的所有条目并删除与被销毁对象匹配的条目。

所以我想我需要的是某种自我意识的常量引用指针索引的东西。

这样的事情存在吗？在我看来，这应该是一个普遍的问题......

例如，在讨论构建或部署过程时，要确保它独立于 IDE。这是“耦合”，还是被认为是关注点分离，还是完全不同的东西？一般概念是在流程或架构中引入最少数量的变量，以便在发生故障时，显着降低识别可能故障点的难度。有其他定义吗？

如何将模式（通常由枚举表示）与其在命令中的实现及其关系中解耦？它们是描述模式开关（int，enum，string，...）与其命令调用之间松散绑定的好模式吗？我想通过配置添加模式，所以这必须（动态）易于扩展（无需编程）。我已经知道命令模式（C#/.Net 中的 ICommand）。它可能是命令字典及其相关的模式编号，但切换逻辑呢？