追逐OO（一）-OOD理论指导

面向对象设计的理论以前也零零碎碎的看过。不过始终觉的自己像个门外汉，2010年刚刚开始，打算今年系统的探索和实践OOD的方方面面！

看到园子里张逸的一个OOD的PDF。感觉总结的很好。这个总结就像是一个提纲，每一个地方都值的深入学习。

我呢，站在巨人的肩膀上，把这个提纲照搬过来，作为学习OOD的指引。

下面所说的封装、继承和多态，个人感觉关键是在“抽象”二字，此处的“抽象”也可以理解为“抽象能力”。

封装是对数据和行为的抽象，合理的隐藏（数据、实现、变化）+合理的公开会产生出一个合理的对象。

从对象的构建到对象的优化无处不在的就是“抽象”。

类继承或是接口继承，抽象类是对一类事物的高度聚合，而接口是对行为的统一规范。所以设计超类或接口，本身就是对系统的高度抽象。

面向对象设计 OOD
三要素：封装、继承、多态
五原则：单一职责原则、开放-封闭原则、Liskov替换原则、依赖倒置原则、接口隔离原则
六观点：复用、扩展、分离、变化、简约、一致
一、面向对象三要素
封装(Encapsulation)
    即合理的隐藏
         数据的隐藏（隐藏在方法背后）
         实现的隐藏（隐藏在接口背后）
         变化的隐藏（隐藏在抽象背后）
    优点
        提供对象的复用性
        降低对象的耦合度
   良好的封装=对象的高内聚
继承(Inheritance)
     基于差异式编程
     继承与合成/聚合
         合成/聚合复用原则
     继承方式
         类的继承
         接口继承
    继承与实现
多态(Polymorphism)
     多态是指对象在不同时刻体现为不同类型的能力
     抽象与多态
     多态的形式：
          基类继承式多态
          接口实现式多态
二、面向对象五原则
单一职责原则(SRP)
     单一职责原则保证了：
         对象的细粒度——便于复用
         对象的单一性——利于稳定
     单一职责原则分离了不变与变
     不要创建“上帝”类，Facade类除外
开放-封闭原则(OCP)
    对于扩展是开放的，对于更改是封闭的
    开放-封闭原则的关键是“抽象”
    多态保证了扩展的开放性
    开放意味着实现是可替换的
Liskov替换原则(LSP)
    子类型必须能够完全替换其父类型
    Liskov替换原则关注的是行为的可替换
    Liskov替换原则：
        可以作为验证继承关系(is-a)正确性的准则
        体现了多个实现在接口的一致性
        如果违背该原则，通常的做法是引入一个新的超类，将父子关系修改为兄弟关系
依赖倒置原则(DIP)
     面向接口编程
     抽象不应该依赖于细节。细节应该依赖于抽象。
     高层模块和低层模块以及客户端模块和服务模块都应该依赖于接口，而不是具体实现
     依赖倒置原则的核心是“抽象”和“间接”
接口隔离原则(ISP)
    接口尽量小，防止接口污染；
    接口若要稳定，就应承担较少责任，本原则同时符合单一职责原则。
    使用多个专门的接口比使用单一的总接口好；
    可以合理利用接口的继承；
    同一个类可以同时实现多个接口，站在调用者的角度，不同的接口代表不同的关注点，不同的职责，甚至是不同的角色。
三、面向对象六观点
复用(Reusibility)
   软件设计最大的敌人是重复。
    重复的代码会导致解决方案蔓延。
    细粒度、封装复用、高内聚
    相关模式：
       Prototype模式
       Proxy模式
    如何提高软件的复用性？
        方法级
             重构之方法提取
             辅助方法
             利用静态工厂复用对象的创建逻辑
       对象级
            遵循单一职责原则
            合理的封装
            辅助类
            AOP（面向方面编程）
      模块级
           根据依赖关系划分包
           复用的粒度就是发布的粒度
          一个包中的所有类应该是共同复用的
扩展(Extensibility)
      不修改原有代码增加新的功能，谓之扩展
      实现扩展的方式：
           利用继承实现扩展
           利用组合实现扩展
           利用继承和组合实现扩展
           利用抽象实现扩展
     相关设计模式
           Decorator模式
           Visitor模式
           Proxy模式
分离(Separability)
      软件设计需重视职责的分离
      分离需与抽象结合，实现依赖的解耦
      职责分离体现了
           单一职责原则
           接口隔离原则
     职责分离表现为
          如何定义职责
          如何分解职责
          如何抽象职责
    分离的目标
         分离变与不变
         分离接口与实现
         分离数据与行为
    相关设计模式
         Factory Method模式
         Bridge模式
         Iterator模式
变化(Change)
    封装变化是解决之道
     封装变化的核心是抽象
          封装创建的变化
          封装结构的变化
          封装行为的变化
     解决变化应遵循：
          开放-封闭原则
          依赖倒置原则
     封装变化的本质是隔离变化
     隔离变化
          通过分离
          通过抽象
         依赖注入
     相关模式
          Factory Method模式
          Abstract Factory模式
          Strategy模式
简约(Simplicity)
     简约需遵循：
          KISS原则
          场景驱动设计
          避免设计过度
     如何实现简约：
          封装有利于简约：职责的封装
          继承有利于简约：职责的复用
          多态有利于简约：职责的委托
     简约不等于简陋，等于简单加优雅
     简约需要重构和精益求精
     如何考量简约？
          可复用性
          可扩展性
          可测试性
     相关模式
          Facade模式
          Singleton模式
          Composite模式
          Template Method模式
          Strategy模式
一致(Coherance)
     一致体现了软件结构的和谐与平衡
      一致体现为：
           接口的一致——对于实现可替换
           形式的一致——窥一斑而知全豹
           调用的一致——客户可透明访问
     相关模式：
          Composite模式
          Adapter模式