8高级面向对象思想概要.ppt

8.1 循环依赖问题 8.1.1 分层模式 8.1.2 循环依赖 8.1.1 分层模式 分层模式在1.1节中阐述逐步求精时提到，它能够显著降低人的思维深度，从而聚焦在当前缩小范围的问题解决上。 分层的6点原则 1）级别相同，职责类似的类应组织入同一层，往来频繁具有双向消息的类应组织入同一层； 2）应尽量将可能发生变化的类提出放到一层中，于是变化发生时只要改变该层，使得修改影响最小； 3）层与层间的耦合应尽可能松散，这样，只要保证接口一致，某层的具体实现就很容易被扩展修改或替换； 4）避免循环依赖。如有可能，应尽可能将直接依赖调整为间接依赖使得变化来临时容易动态加载适应。 5）每层只能单向调用下层服务，不得调用上层的服务，原则上不得跨层调用； 6）复杂的模块应继续逐步求精分解到粒度更细的层或子系统； 8.1 循环依赖问题 8.1.1 分层模式 8.1.2 循环依赖 8.1.2 循环依赖 前述的6条原则中： 对于第5条，上层调用下层提供的服务，但为避免形成循环依赖不允许下层调用上层的接口，实际应用时往往需要变通来符合。比如，上层定义了一些数据结构是本层和下层都要使用的，并且上层还要调用下层的一些服务，客观上这已经形成了循环依赖。 一些例子 再来看这样的一些模块结构图： 消去方法1 提取上层中被下层访问的部分，将其作为一个独立不属于任何层可被大家都依赖访问的应用包存在。 如此一来，系统分层模型中要么是各层对公有包的依赖访问，要么是上层对下层的单向依赖访问，没有循环依赖。 局限性 但这种方法并不适合所有情形，比如当下层需要处理上层的信息是变化的而不是固定不变的数据类型或变量时，提取出公有应用包变得困难，需要变通的办法来逆转访问的方向。 常见的一种情形是：处于上层的显示层需要经常更新，下层的业务逻辑层在处理得出新数据后负责显示层的更新，但又不能直接去调用显示层更新重绘的接口（原则5）。现改为由业务逻辑层维护一个数据结构，显示层在该数组中注册信息（上层访问下层数据结构）。当业务逻辑层完成数据处理需要更新显示层时，直接操作本层该数据结构。 消去方法2 借鉴观察者模式 实际上，如果底层维护的数据结构是一个通用数组，就能够屏蔽因上层对象数量、类型等变化而要求底层服务大幅度修改的难题。 将上层注册在底层的数组中，底层通知上层时无须访问上层，只需遍历该数组即可。 结合使用针对抽象编程，底层与上层对象的具体类型解耦而只与接口耦合，而接口可以是作为公用的应用包存在并且相对稳定。 因此，当一方发生变化时，新增该变化所需的新类和对象，并使用注册机制来动态加载该类对象，而另一方则保持稳定不需要修改业务逻辑代码（仍然是遍历访问其自身上的通用数组）。 8.2 MVC模式 8.2.1 模式的目的 8.2.2 模式基本结构 8.2.3 模式的不足 MVC模式的设计目的 （1）把负责界面显示或用户输入的对象和负责业务操作的对象分开，使用户界面相关代码不必关心如何完成业务操作等问题，而业务代码也不必关心如何和用户交互。 （2）上述两类对象分离后，它们可以相互独立地发生变化，而不会给对方造成影响。例如，界面是软件中较易发生变化的部分，使用MVC模式后，开发者可以相对独立地改变用户界面的代码。 （3）两类对象可以交由不同的项目组分工并行开发，同时可保证系统代码的可读性、易维护性和可扩展性。 （4）在一个系统中添加新的数据显示方式（新的视图）非常容易，对系统原有代码没有任何影响。 （5）可用多个视图，从不同角度展现同一份数据内容。 （6）在运行期，软件可根据工作流程、用户习惯或系统状态动态选择不同的用户界面。 （7）两类对象分离后，更多的对象可以成为复用对象。例如，负责业务处理的对象可以很容易被复用于不同的项目中，甚至可以被复用到不同平台的软件系统中。 Model-View-Control模式 MVC模式是最常使用到的分析模式，也是最简单的分层模式。 在1.1节介绍垂直功能分解时，提到任意一个系统应至少被分为“前后台两层”，继续细化下去，可以得到多层系统。 View即“视图层”，Control即“控制层”，Model即“模型层”。分别对应与用户交互的逻辑、切换控制逻辑，以及具体业务逻辑。 （8）负责业务处理的对象可以很容易地脱离用户界面系统。我们能单独地对它们进行测试，也可在另一个项目中以后台的方式调用这些对象的功能，或利用它们进行批量处理。 （9）通过分布式的协议，我们可以很容易地把负责业务处理的对象部署到其他服务器上运行，同时把负责用户界面的对象部署在客户端与前者进行交互。 8.2 MVC模式 8.2.1 模式的目的 8.2.2 模式基本结构 8.2.3 模式的不足 8.2.1 模式基本结构 关于模式结构的理解 图中对关联和依赖做了编号以便展开描述： 1）正向依赖