如何实现软件项目的模块化

时间:2009-08-10 18:48:04

标签: architecture process methodology

实现极度松散耦合的最佳方法是什么?

如果您希望将软件模块化到极端程度,以至于没有任何部件依赖于系统中的任何其他部件,但它们仍然能够进行通信,这意味着我们必须使用(技术不可知)来实现那么这个目标

建议请将此视为头脑风暴...... :)

7 个答案:

答案 0 :(得分:2)

使用某些域分离的数据格式来启用模块之间的通信或交换信息,如XML,RPC,HTTP等。

让不同的团队开发不同的模块,而不让他们彼此交谈或协调他们的努力。设定一个目标,设计一个带有通用接口的统一模块,以便稍后在各种角色的各种系统中使用(当然,在模块的功能范围内)。

答案 1 :(得分:2)

数据。

如果你想松散耦合,答案就是数据。您的程序或组件不会相互“执行功能”,它们会相互传递数据。 (在内部,这可能通过调用方法来完成 - 但除了机制之外,它应该在概念上传递数据。)

如果您的流程中的数据被视为不可变的,那就更好了。

这提供了明确的组件边界,并在很大程度上保护了您的变化(因为您可以相对容易地将一种形式的数据转换为另一种形式的数据)。它还可以很容易地转移到多进程或网络应用程序,因为数据传递的语义在任何地方都是相同的 - 没有传递一些新的数据就不会假设神奇的隐藏状态变化。

定义良好的接口传递数据,而且你是金色的。我的意思是数据 - 而不是那些知道如何做各种神奇事物的“对象”。简单,纯粹的数据。

顺便说一下 - 这并不是说对象在你的程序中没有位置 - 它们就是对你的数据行事的东西。

此外,请确保将程序中处理数据的部分与程序中负责实际穿梭的部分以及向用户显示的部分分开。我知道,这就是整体'让你的业务逻辑再次与你的持久性和UI层分开'。

答案 2 :(得分:1)

使用Inversion of Control框架,以便组件不必知道如何加载它们的依赖项。

答案 3 :(得分:1)

我认为你提到的内容无法实现,即使可以实现,也很难实现,而且它的优势很少。

模块化可能很好,但有限制。当然,你可以设计你的系统,使一些部分依赖于API,但不是特定的实现,我鼓励这样,但“绝对没有依赖”是一种错觉。 “沟通”很可能会产生依赖。

尝试模块化软件很好,但是你走得太远了。

答案 4 :(得分:1)

让每个系统将其功能公开为REST或WS- *接口。

然而,一个更有趣的问题是你想什么时候这样做?您需要从您选择的技术中挤出尽可能多的生产力/性能,这意味着使用特定于技术的解决方案。

答案 5 :(得分:0)

我认为实现这一目标的唯一方法是使用某种形式的“白板”系统,其中组件在一些通常可访问的区域中记下事实并观察其他组件写下他们的事实。这种架构用于分布式AI系统,但我从未听说过使用它们的真实分布式系统。您的组件显然需要同意“白板”消息的格式,以及实际的实现,例如共享内存。

答案 6 :(得分:0)

100%模块化很可能不值得努力。对于应用程序中的类,可以使用依赖注入和控制反转来松散耦合。

如果您正在谈论更加分散的系统方法,您可以使用SOAP或REST(REST是技术上最中立的方法),以便每个模块提供合同,但在这种情况下,您将需要某种类型的集中式消息传递/路由系统,知道模块的位置和合同,以便可以调用它们并实现某种标准通信以报告成功/失败,除非您的模块通信时希望它进入黑洞永远不会被再次听到:)

请记住,你的概括越多,调试,维护,理解就越困难,如果你的应用程序需要任何性能,这些方法将是你可能做的最慢的事情。