最近我看到很多关于如何构建松散耦合应用程序的博客文章。在创建松散耦合的应用程序时，您最常使用哪种模式？依赖注入？控制反转？
【问题讨论】：
标签： dependency-injection inversion-of-control loose-coupling
除此之外：阻止我编写耦合应用程序的不仅仅是模式：
命名。如果我不能轻易地为我的班级想一个名字，那么它要么什么都不做，要么做的事情太多。
可测试性。如果我不能轻松地模拟出我的类的依赖关系，那就是耦合设计。
【讨论】：
我发现自己经常使用Command 模式。这是一种模式，不断地提供一个又一个项目。
【讨论】：
spring 的依赖注入是我最喜欢的。此外，在 Maven 中，将所有实现隐藏在 API 模块后面是很常见的。所以如果你的代码有三个模块，“application-core”、“externalsystems-api”和“externalsystems”，你可以让“application-core”只依赖于externalsystems-api。实际实现及其所有依赖项对于应用程序核心模块是完全不可见的。这确实加强了关注点的分离，并使松散耦合更容易。
巧妙的是，加载这些 maven 设置的 IDE 会强制执行这些可见性约束。因此，您将无法在应用程序核心中引用 SQL、AXIS、JAXB 或其他任何内容
【讨论】：
一些 SOA 相关模式（例如企业服务总线）提供更高级别的抽象，并支持业务服务和技术服务之间的关注点分离。然后（可以说）通过引入解耦解决方案中的服务的代理或总线来支持服务之间的松散耦合。
【讨论】：
Visitor pattern 效果很好
【讨论】：
我认为基本技巧之一是“告诉不问原则，得墨忒耳法则”。也许它不像 DI、UI 或其他设计模式，但我认为遵循这一原则的对象是松散耦合的，并且可以很好地完成一件事。
“保持害羞，保持干燥告诉其他人”
【讨论】：
是的，重要的是依赖注入和控制反转，但不要忘记抽象工厂和注册表。
【讨论】：
【讨论】：
依赖注入是控制反转的一种形式。
Spring 框架拥有大量 Java 程序员，它也有一个 .NET 实现。
【讨论】：
我很惊讶这还没有被提及 - 策略允许您避免创建对域模型中不同类型了解太多的类。每个策略都负责对涉及特定类型的特定交互进行编码。这避免了创建一个主类型，它知道许多其他类型以及每个类型的实现的细微差别。
来自维基百科：
策略模式使用组合 而不是继承。在里面 定义策略模式行为 作为单独的接口和特定的 实现这些的类 接口。具体类 封装这些接口。这 允许更好的解耦之间 行为和使用的类 行为。行为可以改变 不破坏使用的类 它，并且类可以在 通过改变特定的行为 不需要使用的实现 任何重大的代码更改。 行为也可以在 运行时以及设计时。
【讨论】：
依赖注入和IOC都非常适合解耦代码。
Dotnetrocks show 362 提供了非常好的定义。还可以观看相关的 DNR 电视剧集以更清楚地了解。
【讨论】：
依赖注入是我在我编写的几乎所有类中使用的模式——如果类有依赖，我总是注入它（使用构造函数注入）。只有没有依赖关系的类（即值对象）不使用 DI 模式。能够测试使用 DI 的类是一大优势。
有关 DI 的好处的信息，这两个演示文稿非常好： http://googletesting.blogspot.com/2008/11/clean-code-talks-dependency-injection.html http://googletesting.blogspot.com/2008/11/clean-code-talks-global-state-and.html
使用 DI 模式不需要 DI 容器，但是当程序变大（几十个类或许多范围）时，DI 容器可以减少很多样板。在 JVM 上，我的默认选择是 Guice。
【讨论】：
控制反转作为整体代码/架构风格。
DI 作为一种配置 IoC 的机制。
本地抽象（我称之为“理想环境开发” - 写得好像你有你想要的确切环境）。
对象通常使用 void 方法和通过传递数据进行通信，而不是使用 getter/setter。
我从不直接在核心业务类中使用依赖项——它总是被抽象为本地抽象，并且显式桥接处理依赖项。
我发现这种组合可以实现极其灵活的代码，并具有非常组合的感觉。
【讨论】：