最近我看到很多关于如何构建松耦合应用程序的博客文章。在创建松散耦合的应用程序时，您最常使用哪些模式？依赖注入？控制倒置？
答案 0 :(得分：13)
除此之外：阻止我编写耦合应用程序的因素不仅仅是模式：
命名。如果我不能轻易想到我班级的名字，那么它可以做任何事情或做太多事情。
可测。如果我不能轻易地模拟我的类的依赖，那就是一个耦合设计。
答案 1 :(得分：7)
我发现自己经常使用Command模式。这是一种模式，只是在项目之后继续提供项目。
答案 2 :(得分：6)
春天的依赖注入是我的最爱。另外，对于maven来说，通常这样做是非常巧妙地隐藏API模块背后的所有实现。因此，如果您的代码有三个模块，“application-core”，“externalsystems-api”和“externalsystems”，您可以使“application-core”仅依赖于externalsystems-api。实际实现及其所有依赖关系对于应用程序核心模块完全不可见。这实际上强化了关注点的更难分离，并使松散耦合变得更容易。
巧妙的是，加载这些maven设置的IDE会强制执行这些可见性限制。因此，您无法在应用程序核心中引用SQL，AXIS，JAXB等任何内容
答案 3 :(得分：2)
我认为其中一项基本技术是“告诉不要求原则，德米特定律”。也许它不像DI，UI或其他Desing Patterns，但我认为放弃这个原则的对象是松散耦合的，并做好一件事。
“保持害羞让它干涸告诉另一个人”
答案 4 :(得分：2)
一些与SOA相关的模式（例如，企业服务总线）提供了更高层次的抽象，并支持业务服务和技术服务之间的关注点分离。然后（可以说）通过引入解决方案中的服务的代理或总线来支持服务之间的松散耦合。
答案 5 :(得分：2)
Visitor pattern效果很好
答案 6 :(得分：1)
是的，重要的是依赖注入和控制反转，但不要忘记抽象工厂和注册表。
答案 7 :(得分：1)
答案 8 :(得分：1)
依赖注入是一种控制反转的形式。
Spring Framework有很多Java程序员，它也有.NET实现。
答案 9 :(得分：1)
我很惊讶尚未提及 - 策略允许您避免创建对域模型中的不同类型了解太多的类。每种策略都负责编纂涉及特定类型的特定交互。这样可以避免创建一个知道许多其他类型的主类型以及每个类型的实现细微差别。
来自维基百科：
策略模式使用组合 而不是继承。在里面 战略模式行为被定义 作为单独的接口和具体 实现这些的类 接口。具体课程 封装这些接口。这个 允许更好地解耦 行为和使用该类的类 行为。行为可以改变 不破坏使用的类 它，类可以在之间切换 通过改变具体的行为 实施使用不需要 任何重要的代码更改。 行为也可以改为 运行时和设计时。
答案 10 :(得分：0)
依赖注入和IOC都非常适合解耦代码。
Dotnetrocks show 362提供了非常好的定义。还要观看相关的DNR电视剧集，以便更清楚地了解。
答案 11 :(得分：0)
依赖注入是我在几乎所有类中使用的模式 - 如果类具有依赖性，我总是注入它（使用构造函数注入）。只有没有依赖关系的类（即值对象）才使用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。
答案 12 :(得分：0)
控制反转作为整体代码/架构风格。
DI作为配置IoC的机制。
本地抽象（我称之为“理想环境开发” - 写作就好像你有你想要的完全环境一样）。
对象通常使用void方法进行通信，并通过传递数据，而不是使用getter / setter。
我从不直接在核心业务类中使用依赖项 - 它总是被抽象为本地抽象，而显式Bridge处理依赖项。
我发现这种组合允许非常灵活的代码，并且具有非常有组合感。