模式8:Independent Deployment

 由  Ruici 发布

模式描述

模块应该是可以被独立部署的单元

具体描述

如果一个模块可以被独立部署,那么它就不可以依赖其他的任何模块。但另一方面,除去所有的对外依赖显然是不太现实的。我们希望能够尽可能的减少模块之间的耦合,但是另一方面各个模块为了能够一起协作实现某项功能,耦合又会不可避免的存在。

由于一定程度上的耦合关系是必需的,以面向对象方法为例,系统中就会存在贯穿于多个不同模块的“协作对象”。为了提高维护性以及增强可复用性,使模块之间的耦合关系最小化是非常重要的

实现变种

如果两个模块之间必须存在交互,那么可以在其中一个模块里创建接口或者是抽象类来表示这种交互(或者说依赖关系)。而它们的具体实现则是在运行时动态确定的,同时也是可以动态插拔的。这样就去除掉了编译时的依赖关系,并且提供了更灵活的动态特征。有两种不同的方式来实现这种运行时的模块绑定(wire):首先可以使用工厂模式来创造具体实现的实例;其次是通过External Configuration模式。

在开发可复用的模块时,我们遇到的问题是很难一次性就将模块的可复用性做到最好,通常情况下模块都是需要经过在大量不同的环境中进行大量的实际应用以及不断的改进才能成为一个真正可复用的模块。其实问题的难点与挑战就在于需要去预测其它模块会如何使用它

事实上,预测未知的行为似乎有些不太可靠。其实更好的办法是针对最原始的最简单的需求来设计模块,同时对于已知的其它模块对它的要求来进行复用性设计。虽然并不完美,但你会发现简单可靠工作往往能够比复杂、难以理解的设计会明显更有利于未来的复用。

结果

模块之间的依赖过多会使得管理难度增加,并且会降低模块的可复用性和可测试性。而完全独立不与外界进行任何交互的模块又没有什么价值。所以在大多数场景下,尽可能让更多的模块可以独立部署时一个不错的选择,一个极端的例子是系统中的所有模块都可以独立的运行起来。

总结

在软件系统中保持每一个模块的独立性是不太可能的。一定程度上的模块间耦合关系对于复杂系统而言是必需的。但是一些模块被复用的可能性是更高的,我们可能需要通过使用其它模式来增强这些模块的独立性。

查看评论