第5章面向对象的程序设计与实现ppt课件.ppt

第5章面向对象的程序设计与实现5.1.1程序优化原则
程序优化包括三方面内容：界面优化、持久化优化和业务逻辑优化。
界面优化又分为三部分：界面逻辑优化、界面显示优化和界面结构优化。（P125，5.1.1下面第二段）
持久化优化是指在充分考虑并发性的前提下如何高效地实现实体对象持久化。
本章所述“优化”指的是对于业务逻辑的面向对象优化。
1、不良代码设计的表征
①重复代码
②过长的函数(函数内的分工不明确，不好理解）
③“全能”类
（类内功能太多，造成类间高耦合）
④过长的参数列表（容易产生混乱）
⑤过多的注释（程序本身很晦涩）
⑥出现Switch语句（分支语句的修改，需要检查其他语句）
⑦过多使用其他类的方法和对象
⑧出现无用类或功能很弱的类（考虑与其他的类合并）
2、代码设计原则
（1）严格保证类的封装性
①所有数据都应该隐藏在类的内部
P127下面的代码
②类的使用者必须依赖类的公有接口，但类不能依赖它的使用者
③包中的所有类对于同一类性质的变化应该是共同封闭的
④把相关的数据和行为集中放置
（类间有大量获取的数据，意味着类划分不当）
（2）合理使用继承关系(♥P128♥)
①合成、聚合优先原则
合成表示一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样，打个比方：人有两个胳膊，胳膊和人就是部分和整体的关系，人去世了，那么胳膊也就没用了，也就是说胳膊和人的生命周期是相同

聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但是B对象并不是A对象的一部分，打个比方：人是群居动物，所以每个人属于一个人群，一个人群可以有多个人，所以人群和人是聚合的关系

父类对子类透明，白箱复用。
子类的实现和它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化
当你复用子类的时候，如果继承下来的方法不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换
这种依赖关系限制了灵活性，并最终限制了复用性
而合成/聚合，容器对象只能通过被包含对象的接口来存取被包含对象，不关心被包含对象的细节，黑箱复用。②不要使用多重继承
③类的继承层次不要太多（2-4层为宜不要超过6层）
④父类不应依赖于子类
⑤父子代换原则（P130)
父代能做的，子代也必须可以做
（3）正确进行抽象
抽象是什么？
抽象是指忽略掉对象的细节，把重要的共同点提取加工形成父类。
①最小接口原则（使用多个小接口好于一个大接口）
②单一职责原则（一个子类做好只表示一种抽象，否则子类多重继承）
③开－闭原则（一个软件应该是被扩展而非修改）。
④依赖倒转原则
传统的过程性系统设计办法倾向于使高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。这实际上就是微观决定宏观，战术决定战略，偶然决定必然。依赖倒转原则就是要把这种错误的依赖关系倒转过来。怎么才能不倒转呢？

接口的出现。接口只关心我应该给你什么参数，以及我能从你那里得到些什么，至于你怎么做我不管。
这样你内部的修改对我就不构成影响。

实质性的东西就是一句话：我们应该对接口编程，而不是类内的具体过程编程。零耦合(NilCoupling)关系，两个类没有依赖关系，那就是零耦合。
具体耦合(ConcreteCoupling)关系，两个具体的类之间有依赖关系，那么就是具体耦合关系，如果一个具体类直接引用或者调用另外一个具体类就会发生这种关系。
抽象耦合(AbstractCoupling)关系，这种关系发生在一个具体类和一个抽象类（或者接口）之间，这样可以使发生关联的类之间保持最大的灵活性。5.2.1业务逻辑优化
业务逻辑优化需要考虑两件事情：
①怎样将所有业务逻辑中的子事务尽可能均匀地分配到在建系统中去。这里所说的均匀不是平均，而是让系统中各部分充分发挥各自特有的功能，不要出现“越俎代庖”现象。
②如何找到被分解业务的共同部分。业务逻辑在计算机系统中的分解可能使得原本两个貌似没有太多共同之处的业务出现了共同点，找到这些共同点，就找到了系统优化的关键。
对于第一个问题，基本方法就是参照选定系统架构的层次进行分层分配，将业务逻辑中的每个事务分别在所合适的层中加以实现。对于第二个问题，一方面可以通过分析时序图找到逻辑上相同的部分，另一方面可以将该任务向后推，留待静态类优化时再加以解决。
静态类优化指的是抛开业务逻辑，单纯从编程语言本身对系统进行的优化。
以会员卡管理系统中的卡类型管理和会员信息管理为例，结合本章所述面向对象程序优化原则说明如何进行静态类优化。
初始类图静态类的初步优化设计结果将共同方法转移到抽象类的结果静态类优化设计最终结果对代码结构进行优化的时候，首先应该按照“自顶向下”的原则从项目开始梳理整个代码结构。自顶向下优化完毕后，再从代码开始，仔细分析代码段是否应放置在当