问题标签 [coupling]

我坚信后端和前端之间紧密耦合的异端思想：我希望在生成用户界面时自动使用有关后端的现有隐含知识。例如，如果 VARCHAR 列最多包含 20 个字符，则 GUI 应自动限制用户在相关表单字段中键入超过 20 个字符。

而且我对想要定义我的数据库表的 ORM 有强烈的反感，或者基于一些 hack，因为 ORM，每个表都需要有额外的数字 ID 列。

我对 Python 数据库框架进行了一些研究，我认为我可以得出结论，SQLAlchemy 最适合我的心态。

现在，我需要找到一个 Web 应用程序框架，它自然地适合 SQLAlchemy（或等效的），甚至可能适合我对耦合的胃口。“Web 应用程序框架”是指产品/项目，例如 Pyhons、Django、TurboGears、web2py 等。

例如，理想情况下它应该能够：

• 如果被告知这样做，则自动为输入给定列的数据选择合适的表单小部件；例如，如果该列具有与具有 10 个不同值的列的外键，则小部件应将 10 个可能的值显示为下拉列表
• 自动生成 javascript 表单验证代码，如果将字符串输入到即将出现在 INTEGER 列中的字段等，则会向最终用户提供快速错误反馈
• 为数据自动生成一个日历小部件，该小部件将在 DATE 列中结束
• 提示 NOT NULL 约束作为 javascript，它抱怨相关输入字段中的空数据或纯空格数据
• 生成与相关（简单） CHECK-constraints匹配的 javascript 验证代码
• 通过使用准备好的语句和/或验证外部派生数据，可以轻松避免 SQL 注入
• 通过在适当时自动转义传出的字符串，可以轻松避免跨站点脚本
• 使用约束名称来生成对用户友好的错误消息，以防违反约束

所有这些都应该动态发生，因此表格调整会自动反映在前端 - 可能使用缓存机制，因此所有模型自省都不会影响性能。换句话说，我不想在 XML 文件（或类似文件）中重复我的模型定义，因为它已经在我的数据库中仔细定义了。

Python（或任何语言，就此而言）是否存在这样的框架？如果不是：如果我要自己添加上述功能的一部分，那么几个 Python Web 应用程序框架中的哪一个将是最少的？

我一直在研究耦合指标，还研究了DSM。

我一直在使用的工具之一着眼于“模块”与作为分发单元的模块之间的耦合（在本例中为 .net 程序集）。

我觉得我应该对查看包（或命名空间）之间的耦合比关注分发单元更感兴趣。

我应该更关心包/命名空间之间的耦合（确保抽象只依赖于抽象，具体类型依赖于抽象并且它们在依赖关系中没有循环，因此重构和扩展很容易）还是应该关心我是否可以无需更新未更改的分发单元即可部署新版本？

别人衡量什么？

对于它的价值，我的直觉是，如果我专注于包/命名空间耦合，那么分发耦合单元将免费或至少更容易。

得墨忒耳法则表明你应该只与你直接知道的物体交谈。也就是说，不要执行方法链接来与其他对象对话。当您这样做时，您正在与中间对象建立不正确的链接，将您的代码不恰当地耦合到其他代码。

那很糟。

解决方案是让您知道的类本质上公开简单的包装器，将责任委托给与之有关系的对象。

那挺好的。

但是，这似乎导致班级凝聚力低。它不再只是简单地负责它所做的事情，而且它还具有某种意义上的委托，通过复制其相关对象的接口部分来降低代码的内聚性。

那很糟。

真的会降低凝聚力吗？是两害相权取其轻吗？

这是发展的灰色地带之一，您可以在其中讨论界限在哪里，或者是否有强有力的、有原则的方法来决定在哪里划定界限以及您可以使用什么标准来做出决定？

在我的代码上运行 FxCop，我收到以下警告：

Microsoft.Maintainability : 'FooBar.ctor 与来自 9 个不同命名空间的 99 种不同类型相结合。重写或重构方法以减少其类耦合，或考虑将方法移至与其紧密耦合的其他类型之一。40 以上的类耦合表示可维护性差，40 到 30 之间的类耦合表示可维护性中等，低于 30 的类耦合表示可维护性好。

我的班级是来自服务器的所有消息的登陆区。服务器可以向我们发送不同 EventArgs 类型的消息：

“HandleSignOut”和“HandleConnectionTest”方法中的代码很少；他们通常将工作交给另一个类的函数。

如何以较低的耦合使这个类更好？

我刚刚编写了一个小型 XBox 360 无线控制器托管接口，该接口基本上包裹了低级SlimDX包装器库，并为 XBOX 360 控制器提供了一个简单的托管 API。

在内部，该类每 N 毫秒轮询一次游戏手柄，并在检测到控制器底层状态的变化时触发事件。

我正在经历一些计时器的死胡同，这基本上迫使我在两个邪恶中取其较小的一个：

• 要么使我的 XBox360GamePad 类 UI 框架特定（即支持 WPF/WinForms 将被硬编码在类中，并且类必须引用这些框架......）

• 使类完全与框架无关，但强制用户使用 Dispatcher.Invoke / Invoke() 调用来散布他们的代码，以便能够根据生成的事件更新 UI。

如果我选择后一个选项（使代码 UI 不可知），那么我基本上使用“通用” System.Timers.Timer 或任何不依赖 UI 的计时器。在那种情况下，我最终会从无法直接更新 UI 的线程生成/调用事件，即在 WPF 中，我将不得不通过（丑陋的）使用 Dispatcher.Invoke 来发布源自 360 控制器类的每个更新.

另一方面，如果我在 XBox 360 Controller 类中使用 DispatcherTimer 我有一个工作组件可以直接更新 UI 而不会大惊小怪，但是现在我的整个控制器类都与 WPF 耦合，并且它不能在没有被使用的情况下使用依赖于 WPF（即在纯控制台应用程序中）

我正在寻找的是某种解决方案，它可以让我既不依赖于框架，又可以更新 UI，而无需求助于各种 Dispatcher.Invoke() 技术......例如，如果有一个共享的基础所有计时器的类，我可以根据相关场景以某种方式将计时器作为依赖项注入。有没有人成功处理过这类问题？

如何设计松散耦合的系统，这些系统可能经常需要来自彼此的数据，但不一定属于同一类别？

例如，让旧的 Pet-shop 示例更进一步，并创建一个 pet-store 特许经营权。每个宠物商店都有自己的网站，列出他们的联系信息、促销活动和当前库存。

特许经营所有者希望拥有所有特许宠物商店的列表以及联系信息，可能还有一些照片可以在他们的公司网站上找到。他们希望能够更新此信息，并让任何更新都自动双向推送。他们还希望以自动方式向所有商店的站点提供促销信息。

因此，在这种情况下，库存清单由商店“拥有”，联系信息由两个实体部分“拥有”，促销信息由总部“拥有”。由于任意原因，所有这些数据都不能存储在同一个地方。

是否有一些最佳实践或通用策略来应对这种情况？

是否有任何实用程序可以检查一组托管程序集并告诉您一个命名空间中的任何类型是否依赖于另一个命名空间中的任何类型？例如，假设我有一个MyApp.BusinessRules命名空间并且不希望它直接访问 中的任何内容MyApp.GUI，但两个命名空间都在同一个程序集中。我的目标是能够编写一个自定义的 MSBuild 任务来验证各种耦合规则是否被破坏。

到目前为止，我遇到的唯一一个看起来可能会这样做的工具是NDepend，但我想知道是否有更简单的解决方案。

我正在构建一个图形板，例如我面临设计问题的项目。

Main Class 是 Board，它是一个画布，负责在绘制形状时处理鼠标事件。它还具有上下文变量，例如 currentShape 或 snapFlag 来激活网格磁性。

为了处理形状的移动/调整大小/旋转，它们继承自名为 ObjectHandles (flex) 的第三方开源工具。

我有一个 baseShape 扩展 ObjectHandles 主类来覆盖它的一些内部函数，比如 onMove 函数。

当创建一个形状（鼠标向下、移动、鼠标向上）时，这是由 Board 处理的，它知道他自己的 snap 标志。

var mouseUpPoint:Point = boardCanvas.globalToLocal(new Point(event.stageX, event.stageY)); var snapMouseUpPoint = snapPoint(mouseUpPoint.x, mouseUpPoint.y);

在我覆盖的 onMove 方法中，我希望形状能够了解 Board snap 标志及其变化时间。我该怎么做呢 ？

我是否在我的 basicShape 构造函数中将 Board 作为参数传递，以便我可以检查 snap ？

我是否将标志作为参数传递并以某种方式使所有形状都监听变化？

什么是最干净的解决方案？

非常感谢。

正如您在下面看到的，在构造函数中，我正在实例化一个验证对象，因此我可以在 set 方法中验证用户的电子邮件。这种架构是最佳实践还是有缺陷？我可以避免让我的 User 类直接依赖于我的 Validation 类吗？

还有一个相关的问题：当 set 方法收到无效值时，正确的响应是什么？我看到 2 个选项

1. 不要设置值并返回 false
2. 无论如何设置该值，但为该对象设置一个错误属性。（所以如果设置了 User.Error 我知道出了点问题）

我怀疑#1 是最佳实践，因为您可以确保任何对象属性的值始终有效。正确的？

我正在阅读 Steve McConell 的 Code Complete，我正在考虑他在关于松散耦合的部分中给出的示例。它是关于一个计算员工假期数的方法的接口，它是根据员工的入职日期和她的销售额计算的。作者建议将入职日期和销售额作为方法的参数，而不是员工的实例：

代替

争论的焦点是这将方法的客户端解耦，因为它不需要知道有关 Employee 类的任何信息。

我想到了两件事：

1. 提供计算所需的所有参数会破坏封装。它显示了该方法如何计算结果的内部结构。

2. 更难改变，例如当有人决定员工的年龄也应该包括在计算中时。一个人将不得不更改签名。

你怎么看？