问题标签 [coupling]

对我来说，一个好的 MVC 实现的试金石是换出视图是多么容易。由于懒惰，我总是做得非常糟糕，但现在我想把它做好。这是在 C++ 中，但如果我相信炒作的话，它应该同样适用于非桌面应用程序。

下面是一个例子：应用程序控制器必须在后台检查某个 URL 是否存在。它可能会连接到“URL 可用”事件（使用 Boost Signals），如下所示：

那么它Controller::urlAvailable看起来像什么？

这是一种可能性：

对我来说，这似乎是视图和控制器的严重耦合。这样的耦合使得在使用 web 时无法实现视图（协程除外）。

另一种可能：

我偏爱后者，但如果我这样做，似乎会有：

1. 400 亿个这样的信号。对于非平凡的应用程序，应用程序控制器可能会变得很大
2. 给定视图意外忽略某些信号的非常现实的可能性（API 可以在链接时通知您，但信号/插槽是运行时的）

那么您建议如何消除耦合并降低复杂性？提前致谢。

我有一个使用 Microsoft 的Composite Application Library设计的应用程序。我的 shell 定义了几个区域，以便我可以从单独的模块中注入内容。我正在寻找一种可以减少这些区域引入的耦合的设计模式。

在我看到的所有示例中，区域都是使用基础设施项目中的静态类中的字符串定义和访问的。：

这引入了基础设施项目对 shell 的依赖，因为基础设施项目的一部分现在必须与 shell 匹配。如果您尝试访问未定义的区域，CAL RegionManager 会引发异常，因此我必须确保基础设施和外壳项目保持同步。

有没有办法隔离外壳的区域，以便它们仅在外壳内定义（基础设施项目中没有区域名称）？

有没有办法使区域成为可选的，以便即使它们没有所有相同的区域也可以换出外壳？（一个例子：一个shell有菜单和工具栏区域，另一个只有菜单......如果工具栏可用，模块应该能够注入工具栏，如果不可用则不会失败）

更新 - 有关我的架构的更多详细信息

为了回应下面depictureboy的回答，我想描述一下我的系统设置方式......也许会有更多好的反馈。

我将 Infrastructure 和 Shell 项目视为通用库，并且我有几个使用它们的应用程序。Infrastructure 项目提供“框架”代码和资源（如 MVVM 的东西、反射、图标），而我的 Shell 是一个通用主机窗口，具有基本的窗口布局（菜单、工具栏、状态栏、主要内容区域）。这些应用程序都具有相同的外观和行为相似，因为它们共享外壳。

我的应用程序从加载的模块中获得各自的功能，因此我为每个应用程序提供了一个引导程序项目，它将所有内容（基础设施、外壳、模块）组合在一起。

我想如果我需要开发一个与当前应用程序非常不同的全新应用程序，我将能够重用基础设施项目，但不能重用外壳。这就是为什么我对将基础设施项目和外壳解耦感到好奇的原因。

将渲染代码与实际游戏引擎/逻辑代码分开的最佳方法是什么？把它们分开是个好主意吗？

假设我们有一个名为 Knight 的游戏对象。骑士必须在屏幕上呈现给用户才能看到。我们现在有两个选择。要么我们给 Knight 一个Render/Draw我们可以调用的方法，要么我们创建一个渲染器类来负责渲染所有的骑士。

在将两者分开的情况下，Knight 是否应该仍然包含渲染他所需的所有信息，或者这也应该分开？

在我们创建的上一个项目中，我们决定让渲染对象所需的所有信息都存储在对象本身中，但是我们有一个单独的组件来实际读取该信息并渲染对象。该对象将包含诸如大小、旋转、缩放以及当前正在播放的动画等信息，并且基于此渲染器对象将组成屏幕。

像 XNA 这样的框架似乎认为加入对象和渲染是一个好主意，但是我们害怕被绑定到特定的渲染框架，而构建一个单独的渲染组件可以让我们在任何给定的时间更自由地更改框架。

任何人都可以描述面向对象范式中松耦合和紧耦合之间的确切区别吗？

什么是内聚和解耦？我找到了关于耦合的信息，但没有找到关于解耦的信息。

根据得墨忒耳定律，你可以在返回的对象上调用方法吗？

例如

$http->get() 返回一个对象。这算作在 M 中创建/实例化的对象吗？如果你不能在上面调用方法（根据 LoD），你将如何处理这种情况？

我们的项目有大约 40 个具有复杂关系的表。一位同事认为使用长连接查询强制我了解模块之外的表，但我认为我不应该关心与我的模块没有直接关系的表并使用数据访问函数（由负责其他模块的人编写）当我需要他们的数据时。让我澄清一下：

我负责 ContactVendor 模块，该模块使客户能够联系供应商并就某些特定产品展开对话。Products 模块有它自己的复杂表和与封装细节的函数的关系（例如 i18n、激活、产品可用性等......）。现在我需要显示一些与供应商和客户之间的对话相关的产品的产品标题。我可以编写一个长查询，一次性检索产品信息和对话内容（这迫使我了解产品表），或者我可以将相关的 product_id 传递给 get_product_info(int) 函数。

第一种方法显然要求很高，并引入了许多不良做法和我通常认为编程错误的事情。第二种方法的问题似乎是这些访问函数导致的无数迷你查询，当循环尝试使用每个执行单独查询的函数来获取 100 个产品的产品标题时，性能损失是一个问题。所以我被困在“不要对实现编码，对接口编码”和性能之间。什么是正确的做事方式？

更新：我特别担心将来可能对我的模块之外的这些表进行修改。如果产品模块决定改变他们做事的方式怎么办？或出于某种原因修改架构？这意味着其他一些模块会损坏或出现故障，直到将更改集成到它们中。通常的涟漪效应问题。

我有一个包含很少模块（大约 4 个左右）的小型 Python 程序。主模块创建一个元组列表，从而表示许多记录。这些元组可通过一个简单的函数返回给其他模块（比如，get_records()）。

但是，我不确定这是否是好的设计。问题是其他模块需要知道元组中每个元素的索引。这增加了模块之间的耦合，并且对于想要使用主模块的人来说不是很透明。

我可以想到几个替代方案：

1. 使元组元素的索引值可用作模块常量（例如IDX_RECORD_TITLE，、IDX_RECORD_STARTDATE等）。这避免了像title = record[3].

2. 不要使用元组，而是创建一个记录类，并返回这些类对象的列表。优点是类方法将具有不言自明的名称，例如record.get_title().

3. 不要使用元组，而是使用字典。因此，在这种情况下，该函数将返回一个字典列表。优点是字典键也是不言自明的（尽管使用该模块的人需要知道它们）。但这似乎是一个巨大的开销。

我发现元组是 Python 的一大优势（很容易传递复合数据而没有类/对象的编码开销），所以我目前使用 (1)，但仍然想知道什么是最好的方法。

我正在制作一个简单的 3D CAD 软件。在类图中，许多对象需要通过 (x,y,z) 与其他对象进行区分。我创建了一个所谓的“位置”类，但问题是它看起来高度耦合，因为许多类都使用位置。有任何想法吗？

尽管我已经编程了很长一段时间，但在耦合对象方面，我似乎总是把头撞到墙上，所以我想知道是否有人有任何资源或我可以遵循的黄金法则。

让我举一个小例子，没有特定的语言......

让我们暂时忽略 ctors/setters/getters/dtors，只实例化一些东西......

我的问题是..这里的最佳做法是什么...

或者...

或者也许它甚至不重要：S

我正在研究的现实生活中的例子要复杂得多。每当Person做某事时，Lab需要通知每个人，等等，我只是想弄清楚是否有任何原则可以在这里应用。