模块化架构

将单个应用拆分拆分成不同的模块可大大改善设计。20世纪60年代意大利面条代码。 模块化程序，是由不同模块构成，一个模块是一组类的集合，模块中有些类是public级别，外部模块可访问；有些是private基本，外部不可访问。 此外，一个模块会依赖于其他模块，并在较高层次上声明了执行所需的功能性环境。 评价模块好坏： 检测模块间的依赖。 项目都会演进，规模变大。 第一版： 一定要清除所有不必要的交叉引用关系，将API按照逻辑功能进行模块开发。 只要代码开始访问其他无关模块中的内容时，架构退化就不可避免了。 只关注那些对成功至为重要的关键组件 模块化可使项目更加清楚，更好管理模块间的依赖关系，维护更加灵活。一开始就模块化思想进行设计才是王道。

1.模块化计的类型

（1）只与用户界面有关的代码不需要提供对外的API，它完全封闭，只需保证功能可用即可。Favorites 幸运模块 （2）简单又通用的功能类库模块—可使用第三方类源码，（如果直接使用第三方库，拓展会出现问题，此时设计中应该以PDF文档的格式来发布相关的API文档，对相应的规范内容加以说明，同时提供示例代码） 只有真正的模块化处理才能解决多个开发商产品间冲突的问题。模块化架构将规范与具体实现分离，分别放到不同的模块中。 （3）方法 1）定义一个模块专用于存放规范，其文档中覆盖的实际接口和抽象类灯。此模块中至少存放一个小的“入口点”，比如说构造函数或者静态工厂方法，这样客户端代码可通过入口获取具体的实现内容。 模块化类库，不应该通过复制类文件来解决多个开发方类库冲突的问题，因为会导致类文件重复。复制类文件无法与开发商的具体实现分离。 2）一个独立模块对外提供很多接口，再加上一两个工厂类，就可以用了定义一套规范。可以添加一些文档进行说明 3）具体实现，是一个没有直接对外暴露其功能的包，它只依赖那个规范模块和其他一些实现模块，然后通过注册服务的方式，将自己实现的工厂注入到服务系统中。 4）一个客户也可以看成一个模块，同具体实现。 5）但有时候间接依赖也是必须的，有时候规范模块也会依赖实现模块

2.组件定位和交互

模块化目的：实现程序中各个组成部分的松耦合。两个模块如果独立，彼此就不知道对方的存在，通过接口进行交互。 可减少杂乱代码。 运行环境准备工作通常是由一个框架来完成的，使用依赖注入的方式，完成初始化。 （1）定义接口类 （2）继承实现 有参数的构造函数是一种常用的注入方式 模块化开发缺点：执行较慢，毕竟没有免费的午餐。 最好不使用直接调用代码来绑定服务的方式，而使用一种声明的方式进行服务绑定。常用声明方式System.getProperty(“…”)来完成。 另一种方式使用 xml 配置方式，

3.编写扩展点

Java的Lookup就很好，可以参考，它运行外部通过实现该接口来扩展功能。

4.循环依赖的必要性

有些系统循环依赖是很有用的，特别是遗留代码。但如果新代码就像一团乱麻。 对于容器，规则越严格，用户基于该容器开发架构越清晰。 当这一团乱麻无法维护时，只得将它打在一个包里，这样丧失了多模块的好处。 可以作为组件注入机制来避免或者减少循环依赖，从而做到模块间的分离。 当决定模块化开发，就一定保证模块间出现循环依赖。

5.满城尽是Lookup

Java的Lookup很好，但是C++有什么可以替代Lookup的呢 qt的信 槽虽然可以，但是有时反应会很慢。

6.Lookup的滥用

Java的Lookup很好，但不能滥用。如信 槽方式虽好，但滥用会导致系统性能下降。