logo标签列表

你最常使用哪些松耦合的设计模式？

dependency-injectioninversion-of-controlloose-coupling
16

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

只是为了澄清一个重要的观点：在软件开发中，依赖注入（DI）和控制反转（IoC）是相同的，常常可以互换使用。 - Jon Limjap
2
@John：要完全准确，依赖注入实际上是一种控制反转的风格。 - Kev
依赖注入是一种机制，而控制反转是一种编码风格。你可以在没有控制反转的情况下使用依赖注入。你也可以有控制反转而没有依赖注入（至少是基于容器的依赖注入），但这可能会有些棘手。 - kyoryu
13个回答
13

模型 - 视图 - 控制器（Model-View-Controller）。

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

  • 命名。如果我无法轻松地为我的类想出一个名称，那么它要么什么都不做，要么做了太多事情。

  • 可测试性。如果我无法轻松地模拟我的类的依赖项，那么它就是一种耦合设计。

MVC + MVP是一个不错的组合 - 'VC'通常映射到MVP中的视图和Presenter方面。对于GUI，它以MVC作为逻辑分离，以MVP作为物理（类级别）分离。 - kyoryu
7
我发现自己经常使用命令模式。这是一种在项目之后仍然有用的模式。
6
使用Spring进行依赖注入是我最喜欢的。此外，使用Maven时，常见的技巧是将所有实现都隐藏在API模块后面。因此，如果您的代码有三个模块：“应用程序核心”、“外部系统API”和“外部系统”，则可以使“应用程序核心”仅依赖于“externalsystems-api”。实际的实现及其所有依赖项可以对应用程序核心模块完全不可见。这确实强制执行了更严格的关注点分离，并使松耦合更加容易。
好处在于，加载这些Maven设置的IDE会强制执行这些可见性约束。因此，在应用程序核心中，您无法引用SQL、AXIS、JAXB或其他任何内容。
2
我认为其中一项基本技术是“告诉别问原则，洛德米特法则”。也许它不像DI、UI或其他设计模式，但我认为遵循这个原则的对象松散耦合并且做好一件事情。
“保持内敛，保持干燥，告诉别人。”
2

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

2
1

策略模式。

我很惊讶这还没有被提到 - 策略允许您避免创建过多了解域模型中不同类型的类。每个策略负责编码涉及特定类型的特定交互。这避免了创建一个了解许多其他类型及其各自实现细节的主类型。

来自维基百科：

策略模式使用组合而非继承。在策略模式中，行为被定义为单独的接口和实现这些接口的具体类。具体类封装这些接口。这样可以更好地解耦行为和使用行为的类之间的关系。行为可以更改而不会破坏使用它的类，并且类可以通过更改所使用的特定实现来在行为之间切换，而无需进行任何重大的代码更改。行为也可以在运行时以及设计时更改。

1

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

1

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

Spring框架拥有大量的Java程序员，它也有.NET实现。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接