java应用架构设计模块化模式与OSGI读书笔记
dream00csdn 2013-10-23
《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这两个接口打包到独立的模块中。不需要其他的代码变化。
识别模块是设计模块化软件系统的第一步。紧随其后的就是管理这些模块间的关系。模块之间的这些关系称为结合点，系统中的这些地方需要最特别的关注以确保灵活的系统设计。如果没有关注模块间的关系，只是将系统拆分为一系列的模块并不会带来很明显的好处。
