设计模式----看大话设计模式笔记（一）
OOP编程原则：
1.开闭原则（OCP : Open-Close Principle）：对扩展开放，对修改封闭
2.依赖倒置（DIP： Dependency Inversion Principle）: 依赖于抽象，不依赖于具体
3.替换原则（LSP）: 父类能够出现的地方，子类都能够出现。
4.接口隔离原则（ISP）: 接口功能尽可能单一，不要做功能繁多臃肿的接口
5.单一职责原则（SRP）： 就一个类而言，应该仅有一个引起它变化的原因。 如果一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会抑止这个类完成其他职责的能力。
6.合成聚合原则（CARP）： 聚合/组合优于继承
7.迪米特拉原则，最少知道原则（LoD）：就是说一个对象应当对其他对象尽可能少的了解。即只直接与朋友通信，或者通过朋友与陌生人通信。
朋友的定义（或关系）：
（1）当前对象本身。（2）以参量的形式传入到当前对象方法中的对象。（3）当前对象的实例变量直接引用的对象。（4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。（5）当前对象所创建的对象。
实现：
（1）在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。
（2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。
（3）在类的设计上，只要有可能，一个类应当设计成不变类。
（4）在对其它对象的引用上，一个类对其它对象的引用应该降到最低。
（5）尽量限制局部变量的有效范围.
过程：
1.程序编码目标： 可维护、可复用、可扩展、灵活性好
2.通过封装、继承、多态把程序的耦合性降低，使用设计模式使得程序更加灵活、容易修改、易于复用。
3.UML表示图例：
UML框图中属性或者方法前的 +表示public - 表示private #表示protected
聚合是一种弱的拥有关系，A对象可以包含B对象，但是B对象不是A对象的一部分。
合成是一种强的拥有关系，体现了强的部分和整体的关系，部分和整体的生命周期一样。
设计模式：
1.简单工厂模式：
UML框图：
2.策略模式（strategy）：
面向对象编程并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
关键： 找变化点
策略模式：定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化不会影响到使用算法的客户。
最重要的是这些算法是随时都可能相互替换的，这就是变化点。
封装变化，是面向对象很重要的思维方式！
UML框图：
策略模式解析：
策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作只是实现不同，它可以以相同的方式调用所有的算法，减少各种算法类与使用算法之间的耦合
策略模式的strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于分析出这些算法中的公共功能。
策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
不同的行为堆砌在一个类中，就很难避免使用条件语句来选择合适的行为。将这些行为封装在一个个单独的stategy类中，可以在使用这些行为的类中消除条件语句。
策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同的时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。
3.单一职责原则（SRP）：
就一个类而言应该就一个引起它变化的原因。
如果一个类承担过多的职责，就等于把这些职责耦合在一起，当一个职责发生变化时，就可能会消弱或者抑制这个类完成其他职责的能力。这种耦合是一种脆弱的设计，当变化发生时，会带来意想不到的破坏。
软件设计要做的就是发现职责，并且把这些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那个这个类就有多于一个的职责，就应该想办法考虑职责的分离。
4. 开闭原则：
对修改封闭，对扩展开放 ( open for extension, closed for midification )
面对需求，通过增加代码来实现，而不是修改现有的代码，这就是开闭原则的精神所在。
5. 依赖倒置原则：
依赖于抽象而不依赖细节，使用接口、抽象类编程。
里氏替换原则（LSP）： 子类型能够替换掉它对应的父类型。
依赖倒置原则其实是面向对象编程的标志，程序中所有的依赖关系都终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计。
6. 装饰者模式（Decorator）：
UML图：
Component 是定义一个对象接口，可以给这些对象动态的添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator,装饰抽象类，继承了Component,从外类来扩展Component类的功能，但对Component类来说，是无需知道Decorator类的存在的。 至于ConcreteDecorator是具体的装饰对象，起到给Component添加功能的作用。
装饰者模式通过SetComponent()，即具体包装对象通过设置内部聚合的待包装对象，然后调用包装方法，来进行包装。 这样每个装饰对象的实现就和如何使用它分离开了，每个装饰对象不需要关系如何添加到对象链当中。
装饰者模式是为已有功能动态的添加更多功能的一种方式。 当需要添加功能的时候，如果在主类中添加新的字段、新的方法，肯定可以完成，但是这样增加了主类的复杂度，而且增加的这些东西，仅仅是为满足一些在一些特殊情况下才会执行的特殊行为的需要。而装饰者模式提供了更好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它要装饰的对象。当需要执行特殊行为的时候，客户代码就可以根据需要有选择、有顺序的包装对象了。
装饰者模式： 将类的核心功能和装饰功能区分开，可以去除相关类中重复的装饰逻辑。
7. 代理模式（Proxy）： 为其他对象提供一种代理，已提供对这个对象的访问。
UML图：
代理模式的适用场合：
1）远程代理，为一个对象在不同的地址空间提供局部代表，这样可以隐藏为一个对象存在于不同地址空间的事实。
2）虚拟代理，根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。
3）安全代理，用来控制真实对象的访问权限。
4）智能指引，当使用代理访问一个对象时，增加一些内务的处理。
8. 工厂方法（Factory Method）: 定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
UML框图：
工厂方法模式实现时，客户端需要决定实现哪一个工厂来实现运算类，选择判断的问题，还是存在。工厂方法模式将简单工厂的内部逻辑判断移到了客户端来进行。
工厂方法较简单工厂而言，修正了其在开闭原则上的弊端，但是，每添加一个产品，都需要添加一个工厂类，增加了额外的开销。