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

2019-04-14 22:00发布


 《Java
应用框架设计模块化模式与OSGI》这边书前几章都是讲设计模式好处啊,为什么使用模式什么的,然后第7章就实战了重构了,中间还老是跳跃性的说第11章,第9章说明了为什么这么用,看得前几章十分不爽啊。 因此直接从第8章看起: 1.       模块化的设计模式5种模式分别为: 1)  基本模式 主要定义了其它模式的赖以存在的基础元素。基本模式关注将模块作为可重用单元,依赖管理以及内聚,设计出良好的软件系统要遵循基本模式。包含: 管理关系:设计模块关系。 模块重用:强调模块级别的重用。 模块内聚:模块的行为应该只服务于一个目的。 2) 依赖模式    非循环关系:模块关系必须是非循环的。 等级化模块:模块关系应该是等级化的。 物理分层:模块关系不应该违反概念上的分层。 容器独立:模块应该独立于运行时容器。 独立部署:模块应该是独立的可部署单元。 3) 可用性模式          发布接口:使模块的发布接口众所周知。          外部配置:模块应该可以在外部进行配置。          默认门面:为具有底层实现的细粒度模块创建一个门面,使其成为细粒度模块的一个粗粒度入口。 4) 扩展性模式          抽象化模块:依赖模块的抽象元素。          实现工厂:使用工厂创建模块的实现。          分离抽象:将抽象与实现他们的类放在各自独立的模块中。 5) 通用模式          就近异常:异常应该接近抛出他们的类或接口。          等级化构建:按照模块的等级执行构建。          测试模块:每个模块应该有一个应对的测试模块。 ---------------------------------------------   基本模式: 管理关系:设计模块关系 模块和模块之间的关系:          如果修改模块M2的内容,会影响另一个模块M1,那么就可以说M1物理依赖于M2. 关系分为两种: 输入依赖,输出依赖或者二者兼备。 如果有其他模块依赖当前模块中的类,那么就说存在输入依赖。 如果模块依赖其他模块中一个或多个类,那么就说存在输出依赖。
 直接依赖图示:
            Client为输出依赖,service为输入依赖   间接依赖图示: 也叫传递性依赖,间接依赖至少要涉及三个模块,service模块即作为输出依赖也作为输入依赖,service模块作为clientsubsystem模块之间的桥梁,client模块和subsystem模块就有间接依赖关系。若subsystem模块有什么变化可能会影响serviceclientmok 具备过多的输入和输出依赖模块是最难管理的,因为他们被大量其他模块使用,同时本身也使用了大量的模块。同时具备输入和输出依赖的模块需要最大程度上的灵活性,应该通过依赖模式管理这种灵活性。要不惜一切代价避免循环依赖关系。要灵活运用抽象化模块模式和分离抽象模式来管理模块依赖。                                                                                                                                                                                  模块之间的紧耦合是不好,可以通过关系进行反转或者完全消除,来把紧耦合的关系拆开。 书中样例: 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模块。但是,如果想独立测试和部署这两个模块,那该怎么办呢?为了做到这一点,我们需要完全消除他们之间的关系。 只需要把BillDiscountCalculator这两个接口打包到独立的模块中。不需要其他的代码变化。   识别模块是设计模块化软件系统的第一步。紧随其后的就是管理这些模块间的关系。模块之间的这些关系称为结合点,系统中的这些地方需要最特别的关注以确保灵活的系统设计。如果没有关注模块间的关系,只是将系统拆分为一系列的模块并不会带来很明显的好处。