设计模式 小结
Decorator 装饰器-对象结构型模式
案例：在窗口的正文中加入滚动条，边框等修饰性对象，如果不考虑设计模式，当修饰物增加时，缠身的子类可能会重复继承某个单独的父类，如果允许重复计数，那么子类继承的父类数目会很庞大，重复性较多，这违反了单一职责原则。而在装饰器模式中，不是考虑继承的方法，而是把装饰器单独剥离出来，原有的类继续负责原来的职责，装饰器用于添加新的装饰物，继承体系的父类不是像树的上层节点数目一样疯狂增长，而是通过分离出线性无关的元素，组合元素。感觉有点像是动态规划，消除了子问题重复的缺点。其中的“结构型”体现在了改变了子类的产生结构。装饰器类要继承原来的父类，之后和具体的子类组合，装饰器类的实现依赖于原有接口。
Observer 观察者-对象行为型模式
案例：图形用户界面工具箱将用户应用的界面表示与地下的应用数据分离。如果不考虑设计模式，那么增加一个目标或者对象，那么目标或对象就要修改内部代码：update，而且还要集合另外一方的类型。这里的“行为型”体现在把"notify”行为从单独的对象中分给一个新对象obserever，这是一种行为的分离，控制了行为的疯狂增长。
Bridge桥接-对象结构型模式
案例：蜡笔和毛笔，软件和运行平台。将抽象部分与它的实现部分分离（属性和行为），使他们都可以独立地变化。属性类的有个抽象接口，实现类有个实现接口，之间组合耦合，而具体的对象类和实现具体机制继承各自的父类。桥接模式和装饰器模式都是组合的方式，区别见博客，对于使用者来说，不同环境下，调用装饰器模式中的主体，调用的主体是一致的，而在桥接模式中，会根据环境调用不同的主体。
Adapter适配器-类对象结构型模式
案例：绘图编辑器图形类使用文本类部分功能。基于类的模式：但继承和多重继承机制，对象模式：对象组合机制。适配器模式使用两个已有的接口协同工作，不定义新的接口，不考虑各自如何演化，不需要对两个独立设计的类进行重新设计。桥接模式允许修改实现的类。
Abstract factory抽象工厂-对象创建型模式
提供一个常见一系列相关或相互依赖对象的接口，而无需指定他们具体的类。一个抽象工厂创建了一个完整的产品系列。
设计模式基本原则：
设计模式的设计原则：
- “开放--封闭”原则：
设计模式的核心原则。软件实体（类，模块，函数）对于扩展是开放的,对于修改是关闭的 。实现开闭原则的关键就是抽象化。“开放--封闭”原则中，不允许修改的是抽象的类或者接口。允许扩展的是具体的实现类,抽象类和接口在“开-闭”原则中扮演着极其重要的角色 。开闭原则是指类、模块、方法是可以扩展的，但不可以修改。开即对扩张开放，闭即对修改关闭。开闭原则的应用体现在，开发人员应该仅仅对程序中频繁出现变化的地方进行抽象（封装变化点）。对变化点的封装即对变化的修改关闭。对于变化的不确定性，可随时扩展。即 继承的使用。抽象类的运用。 - 封装变化点原则：
这是对"开-闭"原则最好的实现..不要把你的可变因素放在多个类中,或者散落在程序的各个角落..你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起..最好的解决办法是,分块封套你的可变因素!!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!! - 里氏代换原则：
任何基类可以出现的地方，子类也可以出现 。替换原则即是总是保证子类可以替换它的基类。
替换原则的实现。对于一组具有类似属性，方法，变量的类。我们可以提取公共属性，方法，变量做为一个基类（抽象类或者类），使这一组类继承基类，重写虚方法。现在这些继承的类和基类的关系符合Is-A。如基类为鸟，则继承类可以为麻雀，燕子。我们可以说麻雀Is-A鸟，燕子Is-A鸟。
在项目中所有使用子类的地方都可用父类替换，但在调用方法的时候 ，即呈现面向对象编程的多态性。即替换原则，非常重要的原则，也是比较对难的原则。
- 依赖倒转原则：
要依赖抽象,而不要依赖具体的实现。抽象不应当依赖于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程。a、高层模块不应该依赖于低层模块。二者都应该依赖于抽象
b、抽象不应该依赖于细节。细节应该依赖于抽象。
在面向过程的开发语言中分析和设计，总是创建一些高层模块去调用低层模块、策略依赖于细节的软件结构。实际上这种方法的目的就是要定义子程序层次结构，该结构 描述了高层模块怎样调用低层模块。而设计良好的面向对象的程序，正好“倒置”了这种依赖关系。高层模块不再依赖于低层模块，从而低层模块的修改不会影响到高层模块，并且高层模块也是能非常容易的被重用，高层模块和低层模块都影响都依赖于抽象。这样也非常符合强内聚松耦合的编程思想。故该原则也是框架设计的核心原则。
使用传统的过程化程序设计所创建出来的依赖关系结构，策略是依赖于细节的，这是糟糕的，因为这样会使策略受到细节改变的影响，面向对象的程序设计倒置了依赖关系结构，全程细节和策略都依赖抽象，并且常常是客户程序拥有服务接口。
事实上，这种依赖关系的倒置正是好的面向对象设计 的标志所在，使用何种语言来编写程序是无关紧要的。如果程序的依赖关系是倒置的，它就是面向对象的设计。如果程序的依赖关系不是倒置的，它就是过程化的设计。
依赖倒置原则是实现许多面向对象技术所宣称的好处的基本低层机制。它的正确应用对于创建可重用的框架来说是必需的。同时它对于构建在变化面前富有弹性的代码也是非常重要的，由于抽象和细节彼此隔离，所以代码也非常容易维护。
- 单一职责原则：
一个类应该只有一个引起它变化的原因。不论是在设计类，接口还是方法，单一职责都会处处体现，单一职责的定义：我们把职责定义为系统变化的原因。所有在定义类，接口，方法的时候。定义完以后再去想一想是不能多于一个的动机去改变这个类，接口，方法。如果答案是肯定的，说明定义的类，接口，方法则多于一个职责。故违背单一职责，遇到这种情况应该重新细分职责，直到不会出现多种职责的类，接口方法为止（发现职责，并把那些职责相互分离）。单一职责的为最简单的五种原则之一。在软件设计的过程中处处体现。无处不在。 - 接口隔离法则 ：
为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特法则的要求，最好就是实现接口隔离法则。使用多个专门的接口比使用单一的总接口要好.从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口应当简单地代表一个角色，而不是多个角色。多个演员可以同时演一个角色，就象孙悟空的孩儿一样。 - 合成/聚合原则：
要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的。聚合用来表示“拥有”或整体与部分的关系，而合成则用来表示一种强得多的“拥有”关系。在一个合成关系里，部分和整体的生命周期是一样的。合成就象所说的“合成品”，拆开就坏。 - 迪米特法则：
系统中的类,尽量不要与其他类互相作用，减少类之间的耦合度。 一个对象应当对其它对象有尽可能少的了解，两个类不必直接通信，可以通过第三者(抽象)转发这个调用，这个抽象的第三者可以是门面，可以是调停者，甚至是一个抽象类或接口，模块要独立，独立被封装，他们只靠public的API来通信，只要有可能，一个类应当设计成不变类，其属性都应该是私有的，如果一个类有太多的public访问权限的方法，可以考虑使用多个类把一个类的私有方法和公有方法分开。
聚合(Aggregation):
这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.
用来表示拥有关系或者整体与部分的关系。
组合(Composition):
这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.
在一个合成里，部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成
部分的支配权。包括他们的创建和毁灭。
最后总结一下：
聚合：
- 聚合有时能够不依赖部分而存在，有时又不能
- 部分可以独立于聚合而存在
- 如果有一部分遗失，聚合会给人一种不完全的感觉
- 部分的所有权可以由几个聚合来共享，比如打印机
合成：
- 部分某一时刻只能属于某一个组成
- 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
- 倘若对于部分的职责由其他对象来承担的话，组成也就可以放松这些职责。
- 如果组成销毁的话，它必须销毁所有的部分，或者把负责他们的权利转移给其他对象。
设计模式所解决的问题：
通过显示指定类创建对象:
相关的设计模式：简单工厂、工厂方法、抽象工厂。
紧耦合:
相关的设计模式：抽象工厂、命令模式、外观模式、中介者模式、观察者模式、职责链模式等。
对对象表示或实现的依赖:
相关的设计模式：抽象工厂、桥接模式、备忘录模式、代理模式等。
通过生成子类扩展功能:
相关的设计模式：桥接模式、职责链模式、组合模式、装饰模式、观察者模式、策略模式等。
有能方便地修改类:
相关的设计模式：适配器模式、装饰模式、访问者模式等。
对算法的依赖:
相关设计模式： 生成器模式、迭代模式、策略模式、模板方法模式、访问者模式等。
对软硬件环境的依赖:
相关设计模式：抽象工厂模式、桥接模式等。
