java应用架构设计模块化模式与OSGI读书笔记

 《Java应用框架设计模块化模式与OSGI》这边书前几章都是讲设计模式好处啊，为什么使用模式什么的，然后第7章就实战了重构了，中间还老是跳跃性的说第11章，第9章说明了为什么这么用，看得前几章十分不爽啊。

因此直接从第8章看起：

1.       模块化的设计模式5种模式分别为：

1）  基本模式

主要定义了其它模式的赖以存在的基础元素。基本模式关注将模块作为可重用单元，依赖管理以及内聚，设计出良好的软件系统要遵循基本模式。包含：

管理关系：设计模块关系。

模块重用：强调模块级别的重用。

模块内聚：模块的行为应该只服务于一个目的。

2) 依赖模式

   非循环关系：模块关系必须是非循环的。

等级化模块：模块关系应该是等级化的。

物理分层：模块关系不应该违反概念上的分层。

容器独立：模块应该独立于运行时容器。

独立部署：模块应该是独立的可部署单元。

3) 可用性模式

         发布接口：使模块的发布接口众所周知。

         外部配置：模块应该可以在外部进行配置。

         默认门面：为具有底层实现的细粒度模块创建一个门面，使其成为细粒度模块的一个粗粒度入口。

4) 扩展性模式

         抽象化模块：依赖模块的抽象元素。

         实现工厂：使用工厂创建模块的实现。

         分离抽象：将抽象与实现他们的类放在各自独立的模块中。

5) 通用模式

         就近异常：异常应该接近抛出他们的类或接口。

         等级化构建：按照模块的等级执行构建。

         测试模块：每个模块应该有一个应对的测试模块。

---------------------------------------------

 

基本模式：

管理关系：设计模块关系

模块和模块之间的关系：

         如果修改模块M2的内容，会影响另一个模块M1，那么就可以说M1物理依赖于M2.

关系分为两种：

输入依赖，输出依赖或者二者兼备。

如果有其他模块依赖当前模块中的类，那么就说存在输入依赖。

如果模块依赖其他模块中一个或多个类，那么就说存在输出依赖。
 直接依赖图示：

 

 

 

 

 

 

Client为输出依赖，service为输入依赖

 

间接依赖图示：

也叫传递性依赖，间接依赖至少要涉及三个模块，service模块即作为输出依赖也作为输入依赖，service模块作为client和subsystem模块之间的桥梁，client模块和subsystem模块就有间接依赖关系。若subsystem模块有什么变化可能会影响service和clientmok。

具备过多的输入和输出依赖模块是最难管理的，因为他们被大量其他模块使用，同时本身也使用了大量的模块。同时具备输入和输出依赖的模块需要最大程度上的灵活性，应该通过依赖模式管理这种灵活性。要不惜一切代价避免循环依赖关系。要灵活运用抽象化模块模式和分离抽象模式来管理模块依赖。                                                                                                                                                                                 

模块之间的紧耦合是不好，可以通过关系进行反转或者完全消除，来把紧耦合的关系拆开。

书中样例：

Customer类实现了DiscountCalculator接口，并且和bill类有依赖关系

Bill类依赖了DiscountCalculator接口。

因此customer.jar模块依赖billing.jar, customer.jar在构建和运行时都需要billing.jar。

要想单独使用customer.jar时而不需要billing.jar那就需要反转关系来实现了。

1.       反转关系

将Bill重构为一个接口。接下来，为了避免分割包，将Bill接口转移到与Customer类相同的模块中。

 

 

1.       消除关系

反转关系允许独立于billing.jar模块部署customer.jar模块。在反转关系之前，能够独立的测试部署billing.jar模块。在反转关系之后，我们能够独立测试和部署customer.jar模块。但是，如果想独立测试和部署这两个模块，那该怎么办呢？为了做到这一点，我们需要完全消除他们之间的关系。

只需要把Bill和DiscountCalculator这两个接口打包到独立的模块中。不需要其他的代码变化。

 

识别模块是设计模块化软件系统的第一步。紧随其后的就是管理这些模块间的关系。模块之间的这些关系称为结合点，系统中的这些地方需要最特别的关注以确保灵活的系统设计。如果没有关注模块间的关系，只是将系统拆分为一系列的模块并不会带来很明显的好处。