问题标签 [tightly-coupled-code]

我正在用 C++ 为不支持操作系统的嵌入式系统编写一个项目；几乎没有库支持。非常裸机。因此，我的相当多的代码是紧密耦合的（例如，软件触发的中断和它们正上方的层）。

我正在做的部分工作涉及更改串行端口配置，从而驱动 PC 端（UI 端）和微处理器（活动端）的并发更改。到目前为止，我在一个非常小心的增量类型开发中做得很好（一块一块地安装它）。但是，我希望对我的代码在工程意义上的工作更有信心。

对于这种情况，您会推荐什么样的方法/框架？

编辑：

我在 Tern, Inc. 制造的 ACore86 板上使用 AMD186 ES。编译器：Paradigm，免费版（随板提供）。不幸的是，我没有选择改变我正在做的事情。

受此Flex 问题的启发，将事件发送回父应用程序是否被视为更好的做法，而不是从模块内调用父应用程序实例上的方法？对我来说，模块似乎不应该知道父级有哪些方法可用，因为这种方法会导致紧密耦合。

想法？

我认为自我描述/自动描述服务在 SOA 架构中是一件好事，因为（几乎）您知道调用该服务的所有内容都存在于服务契约（例如 WSDL）中。

对我来说，非自我描述服务的示例是 Facebook 查询语言（FQL http://wiki.developers.facebook.com/index.php/FQL），或任何在一个字符串参数中交换 XML 流以进行解析的 Web 服务XML 和执行处理。

最后一个似乎在技术上更加分离，因为从技术上讲，您可以在不对调用者产生技术影响的情况下切换实现，在业务级别处理实现/版本之间的兼容性。另一方面，没有强接口（稀释到服务及其版本中），使服务与现有实现紧密耦合（更难以互换服务并确保完美兼容）。

这个问题与如何使用 SOA 架构实现松散耦合有关

那么，SOA 架构中的自我描述/自动描述服务是松散耦合还是紧密耦合？对 ESB 有什么影响？

任何指针将不胜感激。

想象一下，你 90% 的工作只是在一个非常庞大、非常破碎的网站上对问题进行分类。想象一下，这个网站是用你所见过的最紧密耦合、最不内聚的 PHP 代码编写的，这种代码类型会将原始开发人员添加到你的“一见钟情”列表中。想象一下，这个 Web 应用程序由 4 个非常不同的部分（1 个商业部分、2 个“重新利用”和 1 个定制部分）和一大堆虚拟胶带和垫片组成。想象一下，它包含一种编程实践，其中网站的主要组件实际上依赖于无法正常工作的东西，而修复这些损坏的东西通常会破坏其他东西。想象一下，您从太多糟糕的经历中了解到，更改网站中看似无害的部分，例如拆分“名称” 字段分为两个单独的“第一个”和“最后一个”字段，这将使网站陷入瘫痪，需要数小时的回滚、合并和补丁。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。

以下是您还应该想象的其他一些事情：

• 现在根本没有测试
• 有 googleteen 不同的登录层。有些客户实际上对网站的不同部分有 3 个不同的帐户
• 当我说“紧密耦合”时，我的意思是 include/require 语句的循环可能会像凯尔特结一样映射出来
• 当我说“最不凝聚力”时，我的意思是有些东西的组织方式有点像 MVC，但它并不是真正的 MVC。在某些情况下，您可能需要几个小时才能了解 URI A 是如何映射到文件 B 的
• UI 写得像“突兀”和“不可访问”是当时的流行语

想象一下，是否值得尝试达到中等水平的测试覆盖率？或者你是否应该，在这个想象的场景中，继续尽你所能用你得到的东西，希望，祈祷，甚至牺牲，客户会同意在这些日子里重写，然后你就可以开始写作了测试？

附录

自从你们中的许多人提出以来：我已经接近了在我必须约会的每一次机会中重写的可能性。与我一起工作的营销人员知道他们的代码是垃圾，他们知道这是他们最初选择的“最低出价”公司的错。我可能已经超越了我作为承包商的界限，指出他们花了一大笔钱在我身上为这个网站提供临终关怀，而且通过从头开始重新开发，他们会很快看到投资回报率。我也说过我拒绝按原样重写网站，因为它并没有真正做到他们想要它做的事情。计划是重写 BDD 风格，但将所有关键玩家集中在一个地方很难，我仍然不确定他们是否知道自己需要什么。无论如何，我完全希望这是一个非常大的项目。

感谢您迄今为止的所有反馈！

什么是处理对象并让它们相互交谈的好方法？

到目前为止，我所有的游戏爱好/学生都很小，所以这个问题通常以一种相当丑陋的方式解决，这导致了紧密的集成和循环依赖。这对于我正在做的项目的规模来说很好。

然而，我的项目的规模和复杂性越来越大，现在我想开始重用代码，让我的头脑变得更简单。

我遇到的主要问题通常是关于Player需要了解Map的Enemy，这通常会导致设置大量指针并具有大量依赖项，这很快就会变得一团糟。

我已经按照消息样式系统的思路进行了思考。但我真的看不出这如何减少依赖关系，因为我仍然会到处发送指针。

^{PS：我想这个之前已经讨论过，但我不知道它叫什么只是我的需要。}

这是我的对象

我有一个与 Location 对象紧密耦合的视图。

在我的产品内容视图中，我有一个与 ProductContent 紧密耦合的视图

我收到一条错误消息

我正在传递 Model.ProductLocation 类型的位置，但为什么它仍然出错？

我正在使用 MVC3 C# Razor

我与我的同事就某些逻辑是否属于数据访问层或业务逻辑层进行了辩论。

场景是，BLL 需要一些数据来处理。该数据主要存在于数据库中。我们希望缓存该数据（使用 System.Runtime.Caching），以便在后续请求中快速可用。该体系结构使得 DAL 和 BLL 存在于同一个盒子和不同的程序集中（同一解决方案中的项目）。所以不用担心通过电线或类似的东西击中 DAL。

我的论点是，命中缓存与数据库的决定是 DAL 关心的问题。业务逻辑层不应该关心数据来自哪里，只关心它获取所需的数据。

他的论点是，数据访问层应该是“纯粹的”和“愚蠢的”，任何决定命中缓存还是数据库的逻辑都应该在业务逻辑层中。

在我看来，当目标是保持松散耦合时，他的意思是破坏关注点分离并导致层更紧密地耦合。如果 BLL 是一个特定的程序/ui 函数来决定去哪里获取数据，我可以看到 BLL 可能想要控制的位置，但这里根本不是这种情况。这只是一个非常简单的缓存场景，其中数据库是主数据存储。

想法？

在我的情况下，更好的解决方案是什么，如何设计类以使它们不是很耦合？

我有一个库 (API)，它提供了一些功能（例如，使用subscribe方法订阅流式外汇价格）。我有一个 API 客户端，它告诉 API 它想要获得的价格。API 通过一些接口（例如SubscriptionStatus）和方法提供反馈SubscribeSuccess(Subscription) and SubscribeFailed(Subscription)。在 API 客户端中，我有一个活动订阅列表 ( List<Subscription> activeSubscriptions)。而且我希望 API 客户端只对订阅成功做出反应（只需将订阅添加到列表中）。在其他情况下 - 只需打印要记录的消息。组织订阅侦听器和 API 客户端之间关系的最佳方式是什么？选项可能是：

1. 将 API 客户端实例传递给订阅侦听器，以便它可以调用apiClient.addSubscription(subscription)
2. API客户端实现SubscriptionStatus接口并管理这些事件（失败，内部成功：activeSubscriptions.add(subscription)）。对比：有很多类型的动作，每个动作都有自己的监听器。所以 Api Client 将是真正的大类。
3. 用一种方法定义自己的接口，SubscriptionSuccess(subscription)让API客户端实现？
4. 你的选择？

任何关于主题的想法表示赞赏！

谢谢！

您认为我的业务服务类打开 SqlConnection 是紧密耦合吗？

实际上，业务服务不应该知道具体的数据提供者？！

公共类 UnitService：

如果我的代码封装程度低，我似乎无法理解“紧耦合”的概念。

有人会展示一些“之前”和“之后”的代码来说明这个概念吗？