前两天，和一朋友聊到OO设计原则时，对设计模式有了更深的了解，在这里总结一下，与大家分享。
OO(Object–Oriented )面向对象 
  OO方法(Object-Oriented Method，面向对象方法，面向对象的方法)是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO (Object-Oriented)方法，是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。而每继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。

OO的设计目标：
  • 可扩展性：有了新的需求，新的性能可以容易添加到系统中，不影响现有的性能，也不会带来新的缺陷。
  • 可修改性：系统一部分的代码要修改时不会破坏系统的现有结构，也不会影响到其它的部分。
  • 可替换性：可以将系统中的某些代码替换为相同接口的其它类，不会影响到系统。

设计模式的设计原则：

  • “开放--封闭”原则：
    设计模式的核心原则。软件实体（类，模块，函数）对于扩展是开放的,对于修改是关闭的 。实现开闭原则的关键就是抽象化。“开放--封闭”原则中，不允许修改的是抽象的类或者接口。允许扩展的是具体的实现类,抽象类和接口在“开-闭”原则中扮演着极其重要的角色 。
  • 封装变化点原则：
    这是对"开-闭"原则最好的实现..不要把你的可变因素放在多个类中,或者散落在程序的各个角落..你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起..最好的解决办法是,分块封套你的可变因素!!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!!
  • 里氏代换原则：
    任何基类可以出现的地方，子类也可以出现 。
  • 依赖倒转原则：
    要依赖抽象,而不要依赖具体的实现。    抽象不应当依赖于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程
  • 单一职责原则：
    一个类应该只有一个引起它变化的原因。
  • 接口隔离法则 ：
    为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特法则的要求，最好就是实现接口隔离法则。    使用多个专门的接口比使用单一的总接口要好.从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口应当简单地代表一个角色，而不是多个角色。多个演员可以同时演一个角色，就象孙悟空的孩儿一样。
  • 合成/聚合原则：
    要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的。聚合用来表示“拥有”或整体与部分的关系，而合成则用来表示一种强得多的“拥有”关系。在一个合成关系里，部分和整体的生命周期是一样的。合成就象所说的“合成品”，拆开就坏。
  • 迪米特法则：
    系统中的类,尽量不要与其他类互相作用，减少类之间的耦合度。     一个对象应当对其它对象有尽可能少的了解，两个类不必直接通信，可以通过第三者(抽象)转发这个调用，这个抽象的第三者可以是门面，可以是调停者，甚至是一个抽象类或接口，模块要独立，独立被封装，他们只靠public的API来通信，只要有可能，一个类应当设计成不变类，其属性都应该是私有的，如果一个类有太多的public访问权限的方法，可以考虑使用多个类把一个类的私有方法和公有方法分开。

聚合(Aggregation):

   这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.

  用来表示拥有关系或者整体与部分的关系。

组合(Composition):

这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.

在一个合成里，部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成

部分的支配权。包括他们的创建和毁灭。

最后总结一下：

聚合：

  •  聚合有时能够不依赖部分而存在，有时又不能
  • 部分可以独立于聚合而存在
  • 如果有一部分遗失，聚合会给人一种不完全的感觉
  • 部分的所有权可以由几个聚合来共享，比如打印机

合成：

  • 部分某一时刻只能属于某一个组成
  • 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
  • 倘若对于部分的职责由其他对象来承担的话，组成也就可以放松这些职责。
  • 如果组成销毁的话，它必须销毁所有的部分，或者把负责他们的权利转移给其他对象。

    设计模式所解决的问题：
    通过显示指定类创建对象:
         相关的设计模式：简单工厂、工厂方法、抽象工厂。
    紧耦合:
        相关的设计模式：抽象工厂、命令模式、外观模式、中介者模式、观察者模式、职责链模式等。
    对对象表示或实现的依赖:
         相关的设计模式：抽象工厂、桥接模式、备忘录模式、代理模式等。
    通过生成子类扩展功能:
         相关的设计模式：桥接模式、职责链模式、组合模式、装饰模式、观察者模式、策略模式等。
    有能方便地修改类:
         相关的设计模式：适配器模式、装饰模式、访问者模式等。
    对算法的依赖:
         相关设计模式： 生成器模式、迭代模式、策略模式、模板方法模式、访问者模式等。
    对软硬件环境的依赖:
         相关设计模式：抽象工厂模式、桥接模式等。