16

最近我看到很多关于如何构建松散耦合应用程序的博客文章。在创建松散耦合的应用程序时，您最常使用哪些模式？依赖注入？控制反转？

4

13 回答 13

13

模型-视图-控制器。

另外：阻止我编写耦合应用程序的不仅仅是模式：

  • 命名。如果我不能轻易地为我的班级想一个名字，它要么什么都不做，要么做的事情太多。

  • 可测试性。如果我不能轻松地模拟出我的班级的依赖关系，那就是耦合设计。

于 2008-12-22T13:44:04.727 回答
7

我发现自己经常使用命令模式。这是一种不断提供项目的模式。

于 2008-12-22T13:53:42.977 回答
6

spring 的依赖注入是我最喜欢的。此外，在 Maven 中，将所有实现隐藏在 API 模块后面是很常见的。所以如果你的代码有三个模块，“application-core”、“externalsystems-api”和“externalsystems”，你可以让“application-core”只依赖于externalsystems-api。实际实现及其所有依赖项对于应用程序核心模块是完全不可见的。这确实加强了关注点的分离，并使松散耦合更容易。

巧妙的是，加载这些 Maven 设置的 IDE 会强制执行这些可见性约束。因此，您将无法在应用程序核心中引用 SQL、AXIS、JAXB 或其他任何内容

于 2008-12-22T13:46:08.000 回答
2

我认为基本技术之一是“告诉不问原则，得墨忒耳法则”。也许它不像 DI、UI 或其他设计模式，但我认为遵循这一原则的对象是松散耦合的，并且可以很好地完成一件事。

“保持害羞保持干燥告诉另一个人”

于 2008-12-22T13:56:13.783 回答
2

一些与 SOA 相关的模式（例如企业服务总线）提供更高级别的抽象，并支持跨业务服务和技术服务的关注点分离。然后（可以说）通过引入将解决方案中的服务解耦的代理或总线来支持服务之间的松散耦合。

于 2008-12-22T13:58:20.300 回答
2

访客模式效果很好

于 2008-12-22T14:24:40.043 回答
1

是的，重要的是依赖注入和控制反转，但不要忘记抽象工厂和注册表。

于 2008-12-22T13:43:01.250 回答
1

桥接模式（http://en.wikipedia.org/wiki/Bridge_pattern）

于 2008-12-22T14:19:47.883 回答
1

依赖注入是控制反转的一种形式。

Spring Framework 拥有大量的 Java 程序员，它也有一个 .NET 实现。

于 2008-12-22T14:33:26.047 回答
1

策略模式。

我很惊讶这还没有被提及 - 策略允许您避免创建对域模型中不同类型了解太多的类。每个策略都负责对涉及特定类型的特定交互进行编码。这避免了创建一个主类型，它知道许多其他类型以及每个类型的实现的细微差别。

来自维基百科：

策略模式使用组合而不是继承。在策略模式中，行为被定义为单独的接口和实现这些接口的特定类。特定的类封装了这些接口。这允许在行为和使用该行为的类之间更好地解耦。可以在不破坏使用它的类的情况下更改行为，并且类可以通过更改使用的特定实现在行为之间切换，而无需任何重大的代码更改。行为也可以在运行时和设计时更改。

于 2010-01-07T19:47:56.727 回答
0

依赖注入和 IOC 都非常适合解耦代码。

Dotnetrocks show 362提供了非常好的定义。还可以观看相关的 DNR 电视剧集以更清楚地了解。

于 2008-12-22T14:12:35.340 回答
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。

于 2010-02-22T00:30:29.970 回答
0

控制反转作为整体代码/架构风格。

DI 作为一种配置 IoC 的机制。

本地抽象（我称之为“理想环境开发”——写得好像你有你想要的确切环境）。

对象通常使用 void 方法和通过传递数据进行通信，而不是使用 getter/setter。

我从不直接在核心业务类中使用依赖项——它总是被抽象为本地抽象，并且显式桥接处理依赖项。

我发现这种组合允许非常灵活的代码具有非常组合的感觉。

于 2010-02-22T00:35:03.400 回答