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

2019-04-14 22:00发布

站内文章 / 模拟电子
9327 0 1215

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

热门文章