版本

作者

参与者

完成日期

备注

YanlzFramework_GoF_V01_1.0

严立钻

2020.02.10

#第一篇：6大设计原则篇

++单一职责原则的好处：

++++1、类的复杂性降低：实现什么职责都有清晰明确的定义；

++++2、可读性提高：复杂性降低，那当然可读性提高了；

++++3、可维护性提高：可读性提高，那当然更容易维护了；

++++4、变更引起的风险降低：变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助；

++依赖倒置原则包含三层含义：

++++A、高层模块不应该依赖低层模块，两者都应该依赖其抽象；

++++B、抽象不应该依赖细节；

++++C、细节应该依赖抽象；

++++补充1：抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。

++依赖倒置原则的表现：

++++A、模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

++++B、接口或抽象类不依赖于实现类；

++++C、实现类依赖接口或抽象类；

++++补充1：面向接口编程是OOD（Object-Oriented Design，面向对象设计）的精髓之一。

++依赖的三种写法：

++++第一种：构造函数传递依赖对象：

--在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入。

--public Driver(ICar _car){  this.car = _car;  }

++++第二种：Setter方式传递依赖对象：

--在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入。

--public void SetCar(ICar car){  this.car = car;  }

++++第三种：接口声明依赖对象：

--在接口的方法中声明依赖对象，采用接口声明依赖的方式，该方法也叫做接口注入。

--public void drive(ICar car);

++保证接口的纯洁性：

++++A、接口要尽量小。（这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是由限度的，首先就是不能违反单一职责原则。）

++++B、接口要高内聚。（高内聚就是提高接口、类、模块的处理能力，减少对外的交互。）（在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。）

++迪米特法则对类的低耦合包含以下4层含义：

++++A、只和朋友交流。（类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象。）（两个对象之间的耦合方式：组合、聚合、依赖等）

++++B、朋友间也是有距离的。（一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大；）（尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private，protected等访问权限。）

++++C、是自己的就是自己的。（如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，就放置在本类中。）

++++D、谨慎使用Serializable。（从private变更为public，访问权限扩大了，如果服务器上没有做出相应的变更，就会报序列化失败。）

++如何使用开闭原则：

++++A、抽象约束。（抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放）

--第一：通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；

--第二：参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；

--第三：抽象层尽量保持稳定，一旦确定即不允许修改；

++++B、元数据（metadata）控制模块行为。（尽量使用元数据来控制程序的行为，减少重复开发。）（元数据：用来描述环境和数据的数据，就是配置参数，参数可以从文件中获得，也可以从数据库中获得。）

++++C、封装变化。

--第一：将相同的变化封装到一个接口或抽象类中。

--第二：将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

#第二篇：23设计模式篇

++设计模式的四个境界：

++++境界1（懵懂）：没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕；

++++境界2（认知）：学了几个模式后，很开心，于是到处想着要用自己学过的模式，于是时常造成误用模式而不自知；

++++境界3（了解）：学完全部模式时，感觉诸多模式极其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫；

++++境界4（领悟）：灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代码，以达到无剑胜有剑的境界；

++2B.01、单例模式

//立钻哥哥：Singleton类

class Singleton{

    private static Singleton instance;

    private Singleton(){}    //构造方法让其private，防止外界利用new实例化

//此方法是获得本类实例的唯一全局访问点

    public static Singleton GetInstance(){

if(instance == null){

instance = new Singleton();    //不存在，new实例化一个

}

        return instance;

}    //立钻哥哥：public static Singleton GetInstance(){}

}    //立钻哥哥：class Singleton{}

++2B.02、工厂方法模式

//立钻哥哥：计算器的工厂方法模式实现

//A、先构建一个工厂接口：

interface IFactory{

Operation CreateOperation();

}    //立钻哥哥：interface IFactory{}

//B、然后加减乘除各建一个具体工厂去实现这个接口：

//B.1、加法类工厂

class AddFactory : IFactory{

    public Operation CreateOperation(){

return new OperationAdd();

}

}    //立钻哥哥：class AddFactory:IFactory{}

//B.2、减法类工厂

class SubFactory : IFactory{

    public Operation CreateOperation(){

return new OperationSub();

}

}    //立钻哥哥：class SubFactory:IFactory{}

//B.3、乘法类工厂

class MulFactory : IFactory{

    public Operation CreateOperation(){

return new OperationMul();

}

}    //立钻哥哥：class MulFactory:IFactory{}

//B.4、除法类工厂

class DivFactory : IFactory{

    public Operation CreateOperation(){

return new OperationDiv();

}

}    //立钻哥哥：class DivFactory:IFactory{}

//C、创建一个Operation运算类

public class Operation{

    private double _numberA = 0;

    private double _numberB = 0;

    public double NumberA{

get{  return _numberA;  }

set{  _numberA = value;  }

}

    public double NumberB{

get{  return _numberB;  }

set{  _numberB = value;  }

}

    public virtual double GetResult(){

double result = 0;

return result;

}

}    //立钻哥哥：public class Operation{}

//C、加减乘除类（继承public class Operation{}）

//C.1、加法类，继承运算类

class OperationAdd : Operation{

    public override double GetResult(){

double result = 0;

resutl = NumberA + NumberB;

return result;

}

}    //立钻哥哥：class OperationAdd:Operation{}

//C.2、减法类，继承运算类

class OperationSub : Operation{

    public override double GetResult(){

double result = 0;

result = NumberA - NumberB;

return result;

}

}    //立钻哥哥：class OperationSub:Operation{}

//C.3、乘法类，继承运算类

class OperationMul : Operation{

    public override double GetResult(){

double result = 0;

result = NumberA * NumberB;

return result;

}

}    //立钻哥哥：class OperationMul:Operation{}

//C.4、除法类，继承运算类

class OperationDiv : Operation{

    public override double GetResult(){

double result = 0;

if(NumberB == 0){

throw new Exception(“立钻哥哥：除数不能为0。”);

}

result = NumberA / NumberB;

        return result;

}

}    //立钻哥哥：class OperationDiv:Operation{}

//D、客户端的代码

IFactory operFactory = new AddFactory();

Operation oper = operFactory.CreateOperation();

oper.NumberA = 11;

oper.NumberB = 100;

double result = oper.GetResult();

++2B.03、抽象工厂模式

++2B.04、建造者模式

//立钻哥哥：建造者模型基本代码

//A、Product类：产品类，由多个部件组成

class Product{

    List<string> parts = new List<string>();

//添加产品部件

    public void Add(string part){

parts.Add(part);

}

    public void Show(){

Console.WriteLine(“立钻哥哥：产品 创建 ----”);

foreach(string part in parts){

Console.WriteLine(part);

}

}

}    //立钻哥哥：class Product{}

//B、Builder类：抽象建造者类，确定产品由两个部件PartA和PartB组成，并声明一个得到产品建造后结果的方法GetResult:

abstract class Builder{

    public abstract void BuildPartA();

    public abstract void BuildPartB();

    public abstract Product GetResult();

}    //立钻哥哥：abstract class Builder{}

//B.1、ConcreteBuilder1类：具体建造者类

class ConcreteBuilder1 : Builder{

    private Product product = new Product();

    public override void BuilderPartA(){

product.Add(“立钻哥哥：部件A”);

}

    public override void BuilderPartB(){

product.Add(“立钻哥哥：部件B”);

}

    public override Product GetResult(){

return product;

}

}    //立钻哥哥：class ConcreteBuilder1:Builder{}

//B.2、ConcreteBuilder2类：具体建造者类

class ConcreteBuilder2 : Builder{

    private Product product = new Product();

    public override void BuildPartA(){

product.Add(“立钻哥哥：部件X”);

}

    public override void BuildPartB(){

product.Add(“立钻哥哥：部件Y”);

}

    public override Product GetResult(){

return product;

}

}    //立钻哥哥：class ConcreteBuilder2:Builder{}

//C、Director类：指挥者类

class Director{

    public void Construct(Builder builder){

builder.BuildPartA();

builder.BuildPartB();

}

}    //立钻哥哥：class Director{}

//D、客户端代码，客户不需知道具体的建造过程

static void Main(string[] args){

    Director director = new Director();

    Builder b1 = new ConcreteBuilder1();

    Builder b2 = new ConcreteBuilder2();

//指挥者用ConcreteBuilder1的方法来建造产品

director.Construct(b1);

    Product p1 = b1.GetResult();

p1.Show();

//指挥者用ConcreteBuilder2的安防来建造产品

director.Construct(b2);

    Product p2 = b2.GetResult();

p2.Show();

Debug.Log(“立钻哥哥：建造者模式演示完毕~~”);

}

++2B.05、原型模式

//立钻哥哥：Prototype原型模式

//A、原型类

abstract class Prototype{

    private string id;

    public string Id{

get{  return id;  }

}

    public Prototype(string id){

this.id = id;

}

//立钻哥哥：抽象类关键就是有这样一个Clone方法

public abstract Prototype Clone();

}    //立钻哥哥：abstract class Prototype{}

//B、具体原型类

class ConcretePrototype1 : Prototype{

    public ConcretePrototype1(string id) : base(id){

}

    public override Prototype Clone(){

return (Prototype)this.MemeberwiseClone();

}

}    //立钻哥哥：class ConcretePrototype1:Prototype{}

//C、客户端代码

static void Main(string[] args){

    ConcretePrototype1 p1 = new ConcretePrototype1(“立钻哥哥”);

//克隆类ConcretePrototype1的对象p1就能得到新的实例c1

    ConcretePrototype1 c1 = (ConcretePrototype1)p1.Clone();

}

//补充说明：对于.NET而言，原型抽象类Prototype是用不着的，因为克隆实在是太常用了，所以.NET在System命名空间中提供了ICloneable接口，其中就是唯一的一个方法Clone()，这样只需要实现这个接口就可以完成原型模式了。

++2B.06、适配器模式

++适配器模式的优点

++++优点1：适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。

++++优点2：增加了类的透明性。（我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块是透明的，也是它不需要关心的。）

++++优点3：提高了类的复用度。（源角色在原有的系统中还是可以正常使用，而在目标角色中也可以充当新的演员。）

++++优点4：灵活性非常好。（如果不想要适配器了，删除掉就可以了，其他的代码都不用修改，基本上就类似一个灵活的构件，想用就用，不想要就卸载。）

//立钻哥哥：Adapter适配器模式代码实现

//A、Target类（这是客户所期望的接口。目标可以是具体的或抽象的类，也可以是接口）

class Target{

    public virtual void Request(){

Debug.Log(“立钻哥哥：----普通请求----”);

}

}    //立钻哥哥：class Target{}

//B、Adaptee类（需要适配的类）

class Adaptee{

    public void SpecificRequest(){

Debug.Log(“立钻哥哥：----特殊请求----”);

}

}    //立钻哥哥：class Adaptee{}

//C、Adapter类（通过在内部包装一个Adaptee对象，把源接口转换成目标接口）

class Adapter : Target{

//建立一个私有的Adaptee对象

    private Adaptee adaptee = new Adaptee();

    public override void Request(){

//这样就可把表面上调用Request()方法变成实际调用SpecificRequest()

adaptee.SpecificRequest();

}

}    //立钻哥哥：class Adapter:Target{}

//D、客户端代码

static void Main(string[] args){

    Target target = new Adapter();

target.Request();    //对客户端来说，调用的就是Target的Request()

Debug.Log(“立钻哥哥：----适配器模式演示完毕~~”);

}

++2B.07、装饰模式

//立钻哥哥：Decorator装饰模式的代码实现

//A、Component类

abstract class Component{

public abstract void Operation();

}    //立钻哥哥：abstract class Component{}

//B、ConcreteComponent类

class ConcreteComponent : Component{

    public override void Operation(){

Debug.Log(“立钻哥哥：----具体对象的操作----”);

}

}    //立钻哥哥：class ConcreteComponent:Component{}

//C、Decorator类

abstract class Decorator : Component{

    protected Component component;

//设置Component

    public void SetComponent(Component component){

this.component = component;

}

//重写Operation(),实际执行的是Component的Operation()

    public override void Operation(){

if(component != null){

component.Operation();

}

}

}    //立钻哥哥：abstract class Decorator:Component{}

//D.1、ConcreteDecoratorA类

class ConcreteDecoratorA : Decorator{

//本类的独有功能，以区别于ConcreteDecoratorB

    private string addedState;

    public override void Operation(){

//首先运行原Component的Operation()，再执行本类的功能，如addedState，相当于对原Component进行了装饰。

base.Operation();

addedState = “立钻哥哥”;

Debug.Log(“立钻哥哥：具体装饰对象A的操作”);

}

}    //立钻哥哥：class ConcreteDecoratorA:Decorator{}

//D.2、ConcreteDecoratorB类

class ConcreteDecoratorB : Decorator{

    public override void Operation(){

//首先运行原Component的Operation()，再执行本类的功能，如AddedBehaviour()，相当于对原Component进行了装饰

base.Operation();

AddedBehaviour();

Debug.Log(“立钻哥哥：----具体装饰对象B的操作”);

}

//本类独有的方法，以区别于ConcreteDecoratorA

    private void AddedBehaviour();

}    //立钻哥哥：class ConcreteDecoratorB:Decorator{}

//E、客户端代码

static void Main(string[] args){

    ConcreteComponent c = new ConcreteComponent();

    ConcreteDecoratorA d1 = new ConcreteDecoratorA();

    ConcreteDecoratorB d2 = new ConcreteDecoratorB();

//装饰的方法是：首先用ConcreteComponent实例化对象c，然后用ConcreteDecoratorA的实例化对象d1来包装c，再用ConcreteDecoratorB的对象d2包装d1，最终执行d2的Operation();

d1.SetComponent(c);

d2.SetComponent(d1);

d2.Operation();

Debug.Log(“立钻哥哥：----装饰模式演示完毕~~”);

}    //立钻哥哥：static void Main(string[] args){}

++2B.08、桥接模式

//立钻哥哥：Bridge桥接模式的代码实现

//A、Implementor类

abstract class Implementor{

public abstract void Operation();

}    //立钻哥哥：abstract class Implementor{}

//B.1、ConcreteImplementorA派生类

class ConcreteImplementorA : Implementor{

     public override void Operation(){

Debug.Log(“立钻哥哥：----具体实现A的方法执行----”);

}

}    //立钻哥哥：class ConcreteImplementorA:Implementor{}

//B.2、ConcreteImplementorB派生类

class ConcreteImplementorB : Implementor{

    public override void Operation(){

Debug.Log(“立钻哥哥：----具体实现B的方法执行----”);

}

}    //立钻哥哥：class ConcreteImplementorB:Implementor{}

//C、Abstraction类

class Abstraction{

    protected Implementor implementor;

    public void SetImplementor(Implementor implementor){

this.implementor = implementor;

}

    public virtual void Operation(){

implementor.Operation();

}

}    //立钻哥哥：class Abstraction{}

//D、RefinedAbstraction类

class RefinedAbstraction : Abstraction{

    public override void Operation(){

implementor.Operation();

}

}    //立钻哥哥：class RefinedAbstraction:Abstraction{}

//E、客户端实现

static void Main(stirng[] args){

    Abstraction ab = new RefinedAbstraction();

ab.SetImplementor(new ConcreteImplementorA());

ab.Operation();

ab.SetImplementor(new ConcreteImplementorB());

ab.Operation();

Debug.Log(“立钻哥哥：----桥接模式演示完毕~~”);

}

++2B.09、组合模式

//立钻哥哥：Composite组合模式代码实现

//A、Component为组合中的对象声明接口，在适当情况下，实现所有类共有接口的默认行为。声明一个接口用于访问和管理Component的子部件

abstract class Component{

    protected string name;

    public Component(string name){

this.name = name;

}

//通常都用Add和Remove方法来提供增加或移除树叶或树枝的功能

    public abstract void Add(Component c);

    public abstract void Remove(Component c);

    public abstract void Display(int depth);

}    //立钻哥哥：abstract class Component{}

//B、Leaf组合中表示叶节点对象，叶节点没有子节点

class Leaf : Component{

    public Leaf(string name) : base(name){

}

//由于叶子没有再增加分枝和树叶，所以Add和Remove方法实现它没有意义，但这样做可以消除叶节点和枝节点对象在抽象层次的区别，它们具有完全一致的接口

    public override void Add(Component c){

Debug.Log(“立钻哥哥：----Cannot add to a leaf.---”);

}

    public override void Remove(Component c){

Debug.Log(“立钻哥哥：----Cannot remove from a leaf.---”);

}

//叶节点的具体方法，此处是显示其名称和级别

    public override void Display(int depth){

Debug.Log(new string(‘-’, depth) + name);

}

}    //立钻哥哥：class Leaf:Component{}

//C、Composite定义有枝节点行为，用来存储子部件，在Component接口中实现与子部件有关的操作，比如增加Add和删除Remove

class Composite : Component{

//一个子对象集合用来存储其下属的枝节点和叶节点

    private List<Component> children = new List<Component>();

    public Composite(string name) : base(name){

}

    public override void Add(Component c){

children.Add(c);

}

    public override void Remove(Component c){

children.Remove(c);

}

    public override void Display(int depth){

Debug.Log(new string(‘-’, depth) + name);

foreach(Component component in children){

component.Display(depth + 2);

}

}

}    //立钻哥哥：class Composite:Component{}

//D、客户端代码，能通过Component接口组合部件的对象

static void Main(string[] args){

//生成树根root，根上长出两叶LeafA和LeafB

    Composite root = new Composite(“root”);

root.Add(new Leaf(“Leaf A”));

root.Add(new Leaf(“Leaf B”));

//根上长出分枝CompositeX，分枝上也有两叶LeafXA和LeafXB

    Composite comp = new Composite(“Composite X”);

comp.Add(new Leaf(“Leaf XA”));

comp.Add(new Leaf(“Leaf XB”));

root.Add(comp);

//在CompositeX上再长出分枝CompositeXY，分枝上也有两叶LeafXYA和LeafXYB

    Composite comp2 = new Composite(“Composite XY”);

comp2.Add(new Leaf(“Leaf XYA”));

comp2.Add(new Leaf(“Leaf XYB”));

comp.Add(comp2);

//根部又长出两叶LeafC和LeafD，可惜LeafD每长牢，被风吹走了

root.Add(new Leaf(“Leaf C”));

    Leaf leaf = new Leaf(“Leaf D”);

root.Add(leaf);

root.Remove(leaf);

//显示大树的样子

root.Display(1);

Debug.Log(“立钻哥哥：----组合模式演示完毕~~”);

}

//E、结果显示

++2B.10、享元模式

++享元模式的应用：

++++享元模式的优点和缺点：享元模式是一个非常简单的模式，它可以大大减少应用程序创建的对象，降低程序内存的占用，增强程序的性能，但它同时也提高了系统复杂性，需要分离出外部状态和内部状态，而且外部状态具有固化特性，不应该随内部状态改变而改变，否则导致系统的逻辑混乱。

++++享元模式的使用场景：

--场景1：系统中存在大量的相似对象。

--场景2：细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。

--场景3：需要缓冲池的场景。

++Flyweight模式的适用性：

++++Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。

++++适用性1：一个应用程序使用了大量的对象。

++++适用性2：完全由于使用大量的对象，造成很大的存储开销。

++++适用性3：对象的大多数状态都可变为外部状态。

++++适用性4：如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。

++++适用性5：应用程序不依赖于对象标识。（由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。）

//立钻哥哥：Flyweight享元模式的代码实现

++++Flyweight类，它是所有具有享元类的超类或接口，通过这个接口，Flyweight可以接受并作用于外部状态。

abstract class Flyweight{

public abstract void Operation(int extrinsicstate);

}

++++ConcreteFlyweight是继承Flyweight超类或实现Flyweight接口，并为内部状态增加存储空间。

class ConcreteFlyweight : Flyweight{

    public override void Operation(int extrinsicstate){

Console.WriteLine(“立钻哥哥：具体Flyweight: ” + extrinsicstate);

}

}

++++UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子类。因为Flyweight接口共享为可能，但并不强制共享。

class UnsharedConcreteFlyweight : Flyweight{

    public override void Operation(int extrinsicstate){

Console.WriteLine(“立钻哥哥：不共享的具体Flyweight:” + extrinsicstate);

}

}

++++FlyweightFactory，是一个享元工厂，用来创建并管理Flyweight对象。它主要是用来确保合理地共享Flyweight，当用户请求一个Flyweight时，FlyweightFactory对象提供一个已创建的实例或者创建一个（如果不存在的话）。

class FlyweightFactory{

    private Hashtable flyweights = new Hashtable();

    public FlyweightFactory(){

flyweights.Add(“X”, new ConcreteFlyweight());

flyweights.Add(“Y”, new ConcreteFlyweight());

flyweights.Add(“Z”, new ConcreteFlyweight());

}

    public Flyweight GetFlyweight(string key){

return ((Flyweight)flyweights[key]);

}

}

++++客户端代码：

static void Main(string[] args){

    int extrinsicstate = 22;

    FlyweightFactory f = new FlyweightFactory();

    Flyweight fx = f.GetFlyweight(“X”);

fx.Operation(--extrinsicstate);

    Flyweight fy = f.GetFlyweight(“Y”);

fy.Operation(--extrinsicstate);

    Flyweight fz = f.GetFlyweight(“Z”);

fz.Operation(--extrinsicstate);

    UnsharedConcreteFlyweight uf = new UnsharedConcreteFlyweight();

uf.Operation(--extrinsicstate);

Console.Read();

}

++++结果表示：

具体Flyweight: 21

具体Flyweight: 20

具体Flyweight: 19

不共享的具体Flyweight: 18

++2B.11、代理模式

++代理模式的优点

++++优点1：职责清晰。（真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事务，附带的结果就是编程简洁清晰。）

++++优点2：高扩展性。（具体主题角色是随时都会发生变化的，只要它实现了接口，那代理类完全就可以在不做任何修改的情况下使用。）

++++优点3：智能化。

++代理模式的拓展：

++++立钻哥哥：一般来说代理分为远程代理、虚拟代理、安全代理、智能指引等。（远程代理：也就是为一个对象在不同的地址空间提供局部代理。这样可以隐藏一个对象存在于不同地址空间的事实。）（虚拟代理：是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。）（安全代理：用来控制真实对象访问时的权限。）（智能指引：是指当调用真实的对象时，代理处理另外一些事。）

++++拓展1：普通代理。（普通代理要求客户端只能访问代理角色，而不能访问真实角色，这是比较简单的。）

++++拓展2：强制代理。（强制代理就是要从真实角色查找到代理角色，不允许直接访问真实角色。）

++++拓展3：代理是有个性的。（一个类可以实现多个接口，完成不同任务的整合。也就是说代理类不仅仅可以实现主题接口，也可以实现其他接口完成不同的任务，而且代理的目的是在目前对象方法的基础上作增强，这种增强的本质通常就是对目标对象的方法济宁拦截和过滤。）

++++拓展4：虚拟代理。（虚拟代理（Virtual Proxy），只要把代理模式的通用代码修改成虚拟代理。在需要的时候才初始化主题对象，可以避免被代理对象较多而引起的初始化缓慢的问题。其缺点是需要在每个方法中判断主题对象是否被创建，这就是虚拟代理。）

++++拓展5：动态代理。（动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理哪一个对象。相对来说，自己写代理类的方式就是静态代理。）（要实现动态代理的首要条件是：被代理类必须实现一个接口。）

++代理模式的适用性

++++立钻哥哥：在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用Proxy模式。

++++适用性1：远程代理（Remote Proxy）：为一个对象在不同的地址空间提供局部代表。

++++适用性2：虚代理（Virtual Proxy）：根据需要创建开销很大的对象。

++++适用性3：保护代理（Protection Proxy）：控制对原始对象的访问。（保护代理用于对象应该有不同的访问权限的时候。）

++++适用性4：智能指引（Smart Reference）：取代了简单的指针，它在访问对象时执行一些附加操作。（对指向实际对象的引用计数，这样当该对象没有引用时，可以自动释放它（也称为Smart Pointers）。）（当第一次引用一个持久对象时，将它装入内存。）（在访问一个实际对象前，检查是否已经锁定了它，以确保其他对象不能改变它。）

//立钻哥哥：Proxy代理模式的代码实现

++++Subject类，定义了RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy。

abstract class Subject{

public abstract void Request();

}

++++RealSubject类，定义Proxy所代表的真实实体。

class RealSubject : Subject{

    public override void Request(){

Console.WriteLine(“立钻哥哥Print：真实的请求”);

}

}

++++Proxy类，保存一个引用使得代理可以访问实体，并提供一个与Subject的接口相同的接口，这样代理就可以用来替代实体。

class Proxy : Subject{

    RealSubject realSubject;

    public override void Request(){

if(realSubject == null){

realSubject = new RealSubject();

}

realSubject.Request();

}

}

++++客户端代码：

static void Main(string[] args){

    Proxy proxy = new Proxy();

proxy.Request();

Console.Read();

}

++2B.12、外观模式

++外观模式的优缺点

++++优点1：减少系统的相互依赖。（如果我们不使用外观模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系，这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对外观对象的依赖，与子系统无关。）

++++优点2：提供了灵活性。（依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，任你自由活动。）

++++优点3：提高安全性。（想让访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，休想访问到。）

++++缺点1：外观模式最大的缺点就是不符合开闭原则。（后期维护，继承？覆写？都不顶用，唯一能做的一件事就是修改外观角色的代码，这个风险相当大。）

++外观模式的使用场景

++++场景1：为一个复杂的模块或子系统提供一个供外界访问的接口。

++++场景2：子系统相对独立：外界对子系统的访问只要黑箱操作即可。

++++场景3：预防低水平人员带来的风险扩散。（“画地为牢”，只能在指定的子系统中开发，然后再提供外观接口进行访问操作。）

++外观模式的适用性

++++适用性1：当要为一个复杂子系统提供一个简单接口时。（子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。）（Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过facade层。）

++++适用性2：客户程序与抽象类的实现部分之间存在着很大的依赖性。（引入facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。）

++++适用性3：当需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口点。（如果子系统之间是相互依赖的，可以让它们仅通过facade进行通讯，从而简化了它们之间的依赖关系。）

//立钻哥哥：Facade外观模式的代码实现

++++四个子系统的类

class SubSystemOne{

    public void MethodOne(){

Console.WriteLine(“立钻哥哥Print: 子系统方法一”);

}

}

class SubSystemTwo{

    public void MethodTwo{

Console.WriteLine(“立钻哥哥Print: 子系统方法二”);

}

}

class SubSystemThree{

    public void MethodThree(){

Console.WriteLine(“立钻哥哥Print: 子系统方法三”);

}

}

class SubSystemFour{

    public void MethodFour(){

Console.WriteLine(“立钻哥哥Print: 子系统方法四”);

}

}

++++外观类

class Facade{

    SubSystemOne one;

    SubSystemTwo two;

    SubSystemThree three;

    SubSystemFour four;

    public Facade(){

one = new SubSystemOne();

two = new SubSystemTwo();

three = new SubSystemThree();

four = new SubSystemFour();

}

    public void MethodA(){

Console.WriteLine(“立钻哥哥Print: 方法组A()----”);

one.MethodOne();

two.MethodTwo();

four.MethodFour();

}

    public void MethodB(){

Console.WriteLine(“立钻哥哥Print: 方法组B()----”);

two.MethodTwo();

three.MethodThree();

}

}

++++客户端调用

static void Main(string[] args){

    Facade facade = new Facade();

facade.MethodA();

facade.MethodB();

Console.Read();

}

++++立钻哥哥：外观模式完美体现了依赖倒置原则和迪米特法则的思想，所以是非常常用的模式之一。

++2B.13、观察者模式

++观察者模式特点

++++立钻哥哥：观察者模式的关键对象是主题Subject和观察者Observer，一个Subject可以有任意数目的依赖它的Observer，一旦Subject的状态发生了改变，所有的Observer都可以得到通知。Subject发出通知时并不需要知道谁是它的观察者，也就是说，具体观察者是谁，它根本不需要知道。而任何一个具体观察者不知道耶不需要知道其他观察者的存在。（将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。）

++++当一个对象的改变需要同时改变其他对象，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。（一个抽象模型有两个方法，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。）

++++观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

++事件委托说明

++++立钻哥哥：委托就是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法具有完全相同的行为。（委托方法的使用可以像其他任何方法一样，具有参数和返回值。）（委托可以看做是对函数的抽象，是函数的“类”，委托的实例将代表一个具体的函数。）

++++举例：delegate void EventHandler()；可以理解为声明了一个特殊的“类”。（而public event EventHandler Update; 可以理解为声明了一个“类”的变量。=>声明了一个事件委托变量叫Update）

++++一个委托可以搭载多个方法，所有方法被依次唤起。（可以使得委托对象所搭载的方法并不需要属于同一个类。）

++++委托对象所搭载的所有方法必须具有相同的原形和形式，也就是拥有相同的参数列表和返回值类型。

++观察者模式的优缺点

++++立钻哥哥：Observer模式允许我们独立的改变目标和观察者。（我们可以单独复用目标对象而无需同时复用其观察者，反之亦然。）（观察者模式也使我们可以在不改动目标和其他的观察者的前提下增加观察者。）

++++优点A.1：目标和观察者间的抽象耦合。（一个目标所知道的仅仅是它有一系列观察者，每个都符合抽象的Observer类的简单接口。目标不知道任何一个观察者属于哪一个具体的类。这样目标和观察者之间的耦合是抽象的和最小的。）（因为目标和观察者不是紧密耦合的，它们可以属于一个系统中的不同抽象层次。一个处于较低层次的目标对象可与一个处于较高层次的观察者通信并通知它，这样就保持了系统层次的完整。如果目标和观察者混在一起，那么得到的对象要么横贯两个层次（违反了层次性），要么必须放在这两层的某一层中（这可能会损害层次抽象。））

++++优点A.2：支持广播通信。（不像通常的请求，目标发送的通知不需指定它的接受者。通知被自动广播给所有已向该目标对象登记的有关对象。目标对象并不关心到底有多少对象对自己感兴趣；它唯一的责任就是通知它的各观察者。这给了我们在任何时刻增加和删除观察者的自由。处理还是忽略一个通知取决于观察者。）

++++缺点A.1：意外的更新。（因为一个观察者并不知道其它观察者的存在，它可能对改变目标的最终代价一无所知。在目标上一个看似无害的操作可能会引起一系列对观察者以及依赖于这些观察者的那些对象的更新。此外，如果依赖准则的定义或维护不当，常常会引起错误的更新，这种错误通常很难捕捉。）（简单的更新协议不提供具体细节说明目标中什么被改变了，这就使得问题更加严重。如果没有其他协议帮助观察者发现什么发生了改变，它们可能会被迫尽力减少改变。）

++++优点B.1：观察者和被观察者之间是抽象耦合。（如此设计，则不管是增加观察者还是被观察者都非常容易扩展。）

++++优点B.2：建立一套触发机制。（根据单一职责原则，每个类的职责是单一的，把各个单一的职责串联成真实世界的复杂的逻辑关系，这就是一个触发机制，形成了一个触发链。观察者模式可以完美地实现这里的链条形式。）

++++缺点B.1：观察者模式需要考虑开发效率和运行效率问题，一个被观察者，多个观察者，开发和调试就会比较复杂，消息的通知默认是顺序执行，一个观察者卡壳，会影响整体的执行效率。（在这种情况下，一般考虑采用异步的方式。）（多级触发时的效率更是让人担忧，大家在设计时注意考虑。）

++观察者模式的使用场景

++++场景1：关联行为场景。（需要注意的是，关联行为是可拆分的，而不是“组合”关系。）

++++场景2：事件多级触发场景。

++++场景3：跨系统的消息交换场景，如消息队列的处理机制。

++观察者模式适用性

++++适用性1：当一个抽象模型有两个方面，其中一个方面依赖于另一个方面。（将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。）

++++适用性2：当对一个对象的改变需要同时改变其它对象，而不知道具体由多少对象有待改变。

++++适用性3：当一个对象必须通知其它对象，而它又不能假定其它对象是谁。（换言之，我们不希望这些对象时紧密耦合的。）

//立钻哥哥：Observer观察者模式的代码实现

++++Subject类，可翻译为主题或抽象通知者，一般用一个抽象类或者一个接口实现。它把所有对观察者对象的引用保存在一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。

abstract class Subject{

    private List<Observer> observers = new List<Observer>();

//增加观察者

    public void Attach(Observer observer){

observers.Add(observer);

}

//移除观察者

    public void Detach(Observer observer){

observers.Remove(observer);

}

//通知

    public void Notify(){

foreach(Observer o in observers){

o.Update();

}

}

}

++++Observer类，抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者一般用一个抽象类或者一个接口实现。更新接口通常包含一个Update()方法，这个方法叫做更新方法。

abstract class Observer{

public abstract void Update();

}

++++ConcreteSubject类，叫做具体主题或具体通知者，将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个具体子类实现。

class ConcreteSubject : Subject{

    private string subjectState;

//具体被观察者状态

    public string SubjectState{

get{    return subjectState;    }

set{    subjectState = value;    }

}

}

++++ConcreteObserver类，具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。具体观察者角色可以保持一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现。

class ConcreteObserver : Observer{

    private string name;

    private string observerState;

    private ConcreteSubject subject;

    public ConcreteObserver(ConcreteSubject subject, string name){

this.subject = subject;

this.name = name;

}

    public override void Update(){

observerState = subject.SubjectState;

Console.WriteLine(“立钻哥哥Print: 观察者{0}的新状态是{1}”, name, observerState);

}

    public ConcreteSubject Subject{

get{    return subject;    }

set{    subject = value;    }

}

}

++++客户端代码

static void Main(string[] args){

    ConcreteSubject s = new ConcreteSubject();

s.Attach(new ConcreteObserver(s, “X”));

s.Attach(new ConcreteObserver(s, “Y”));

s.Attach(new ConcreteObserver(s, “Z”));

s.SubjectState = “ABC”;

s.Notify();

Console.Read();

}

++++结果显示：

观察者X的新状态是ABC

观察者Y的新状态是ABC

观察者Z的新状态是ABC

++2B.14、模板方法模式

++模板方法模式特点：

++++特点1：模板方法模式是通过把不变行为搬移到超类，去除子类中的重复代码来体现它的优势。

++++特点2：模板方法模式就是提供了一个很好的代码复用平台。

++++特点3：当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。

++模板方法模式的优缺点

++++优点1：封装不变部分，扩展可变部分。（把认为是不变部分的算法封装到父类实现，而可变部分的则可以通过继承来继承扩展。）

++++优点2：提取公共部分代码，便于维护。

++++优点3：行为由父类控制，子类实现。（基本方法是由子类实现的，因此子类可以通过扩展的方式增加相应的功能，符合开闭原则。）

++++缺点1：按照我们的设计习惯，抽象类负责声明最抽象、最一般的事物属性和方法，实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。

++++模板方法模式的使用场景：

--场景1：多个子类有公有的方法，并且逻辑基本相同时。

--场景2：重复、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。

--场景3：重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束其行为。（有了钩子方法，模板方法模式才算完美，由子类的一个方法返回值决定公共部分的执行结果，是不是很有吸引力呀！）

//立钻哥哥：TemplateMethod模板方法模式的代码实现

++++AbstractClass是抽象类，其实也就是一抽象模板，定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。

abstract class AbstractClass{

//一些抽象行为，放到子类去实现

    public abstract void PrimitiveOperation1();

    public abstract void PrimitiveOperation2();

//模板方法，给出了逻辑的骨架，而逻辑的组成是一些相应的抽象操作，它们都推迟到子类实现

    public void TemplateMethod(){

PrimitiveOperation1();

PrimitiveOperation2();

Console.WriteLine(“”);

}

}

++++ConcreteClass，实现父类所定义的一个或多个抽象方法。每一个AbstractClass都可以有任意多个ConcreteClass与之对应，而每一个ConcreteClass都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。

class ConcreteClassA : AbstractClass{

    public override void PrimitiveOperation1(){

Console.WriteLine(“立钻哥哥Print: 具体类A方法1实现”);

}

    public override void PrimitiveOperation2(){

Console.WriteLine(“立钻哥哥Print: 具体类A方法2实现”);

}

}

class ConcreteClassB : AbstractClass{

    public override void PrimitiveOperation1(){

Console.WriteLine(“立钻哥哥Print: 具体类B方法1实现”);

}

    public override void PrimitiveOperation2(){

Console.WriteLine(“立钻哥哥Print: 具体类B方法2实现”);

}

}

++++客户端调用：

static void Main(string[] args){

     AbstractClass c;

c = new ConcreteClassA();

c.TemplateMethod();

c = new ConcreteClassB();

c.TemplateMethod();

Console.Read();

}

++2B.15、命令模式

++命名模式的作用

++++作用1：它能较容易地设计一个命令队列；

++++作用2：在需要的情况下，可以较容易地将命令记入日志；

++++作用3：允许接收请求的一方决定是否要否决请求。

++++作用4：可以容易地实现对请求的撤销和重做；

++++作用5：由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

++++作用6：命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分隔开。

++++提示：敏捷开发原则告诉我们，不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。

++命令模式的优缺点

++++优点1：类间解耦。（调用者角色与接收者之间没有任何依赖关系，调用者实现功能时只须调用Command抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。）

++++优点2：可扩展性。（Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严重的代码耦合。）

++++优点3：命令模式结合其他模式会更优秀。（命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少Command子类的膨胀问题。）

++++缺点1：如果有N个命令，问题就出来了，Command的子类就有N个，这个类膨胀得非常大，在项目中慎重考虑使用。

++++场景1：只要认为是命令的地方就可以采用命令模式。（在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式。）（触发-反馈机制的处理。）

//立钻哥哥：Command命令模式的代码实现

++++Command类，用来声明执行操作的接口。

abstract class Command{

    protected Receiver receiver;

    public Command(Receiver receiver){

this.receiver = receiver;

}

    abstract public void Execute();

}

++++ConcreteCommand类，将一个接受者对象绑定于一个动作，调用接受者相应的操作，以实现Execute。

class ConcreteCommand : Command{

    public ConcreteCommand(Receiver receiver) : base(receiver){

}

    public override void Execute(){

receiver.Action();

}

}

++++Invoker类，要求改命令执行这个请求。

class Invoker{

    private Command command;

    public void SetCommand(Command command){

this.command = command;

}

    public void ExecuteCommand(){

command.Execute();

}

}

++++Receiver类，知道如何实施与执行一个与请求相关的操作，任何类都可能作为一个接受者。

class Receiver{

    public void Action(){

Console.WriteLine(“立钻哥哥Print: 执行请求！”);

}

}

++++客户端代码，创建一个具体命令对象并设定它的接受者。

static void Main(string[] args){

    Receiver r = new Receiver();

    Command c = new ConcreteCommand(r);

    Invoker i = new Invoker();

i.SetCommand();

i.ExecuteCommand();

Console.Read();

}

++2B.16、状态模式

++状态模式的优缺点

++++优点1：结构清晰。（避免了过多的switch...case或者if...else语句的使用，避免了程序的复杂性，提高系统的可维护性。）

++++优点2：遵循设计原则。（很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，要增加状态就要增加子类，要修改状态，只修改一个子类就可以了。）

++++优点3：封装性非常好。（这是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。）

++++缺点1：状态模式只有一个缺点：子类会很多，类膨胀。（如果一个事物有很多个状态，完全使用状态模式就会有太多的子类，不好管理。）

++++使用场景1：行为随状态而改变的场景。（这是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。）

++++使用场景2：条件、分支判断语句的替代者。（在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。）

//立钻哥哥：State状态模式的代码实现

++++State类，抽象状态类，定义一个接口以封装与Context的一个特定状态相关的行为。

abstract class State{

public abstract void Handle(Context context);

}

++++ConcreteState类，具体状态，每一个子类实现一个与Context的一个状态相关的行为。

class ConcreteStateA : State{

//设置ConcreteStateA的下一状态是ConcreteStateB

    public override void Handle(Context context){

context.State = new ConcreteStateB();

}

}

class ConcreteStateB : State{

    public override void Handle(Context context){

context.State = new ConcreteStateA();

}

}

++++Context类，维护一个ConcreteState子类的实例，这个实例定义当前的状态。

class Context{

    private State state;

//定义Context的初始状态

    public Context(State state){

this.state = state;

}

//可读写的状态属性，用于读取当前状态和设置新状态

    public State State{

get{    return state;    }

set{

state = value;

Console.WriteLine(“立钻哥哥Print: 当前状态：” + state.GetType().Name);

}

}

    public void Request(){

//对请求做处理，并设置下一状态

state.Handle(this);

}

}

++++客户端代码：

static void Main(string[] args){

//设置Context的初始状态为ConcreteStateA

    Context c = new Context(new ConcreteStateA());

//不断的请求，同时更改状态

c.Request();

c.Request();

c.Request();

c.Request();

Console.Read();

}

++2B.17、职责链模式

++职责链模式的优缺点

++++优点1：职责链模式非常显著的优点是将请求和处理分开。（请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌。）

++++缺点1：性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。

++++缺点2：调试不方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。

++++注意事项1：链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在setNext方法中判断是否已经是超过其阀值，超过则不允许该链建立，避免无意识地破坏系统性能。

//立钻哥哥：“Chain of Responsibility”责任链模式的代码实现

++++Handler类，定义一个处理请示的接口。

abstract class Handler{

    protected Handler successor;

//设置继任者

    public void SetSuccessor(Handler successor){

this.successor = successor;

}

//处理请求的抽象方法

    public abstract void HandleRequest(int request);

}

++++ConcreteHandler类，具体处理者类，处理它所负责的请求，可访问它的后继者，如何可处理该请求，就处理之，否则就将该请求转发给它的后继者。

++++ConcreteHandler1，当请求数在0到10之间则有权处理，否则转到下一位。

class ConcreteHandler1 : Handler{

    public override void HandleRequest(int request){

//0到10，处理此请求

if(request >= 0 && request < 10){

Console.WriteLine(“立钻哥哥Print: {0}处理请求{1}”, this.GetType().Name, request);

}else if(successor != null){

//转移到下一位

successor.HandleRequest(request);

}

}

}

++++ConcreteHandler2，当请求输在10到20之间则有权处理，否则转到下一位。

class ConcreteHandler2 : Handler{

    public override void HandleRequest(int request){

//10到20，处理此请求

if(request >= 10 && request < 20){

Console.WriteLine(“立钻哥哥Print: {0}处理请求{1}”, this.GetType().Name, request);

}else if(successor != null){

//转到下一位

successor.HandlerRequest(request);

}

}

}

++++ConcreteHandler3，当请求数在20到30之间则有权处理，否则转到下一位。

class ConcreteHandler3 : Handler{

    public override void HandleRequest(int request){

//20到30，处理此请求

        if(request >= 20 && request < 30){

Console.WriteLine(“立钻哥哥Print: {0}处理请求{1}”, this.GetType().Name, request);

}else if(successor != null){

//转移到下一位

successor.HandleRequest(request);

}

}

}

++++客户端代码，向链上的具体处理者对象提交请求。

static void Main(string[] args){

    Handler h1 = new ConcreteHandler1();

    Handler h2 = new ConcreteHandler2();

    Handler h3 = new ConcreteHandler3();

//设置职责链上家和下家

h1.SetSuccessor(h2);

h2.SetSuccessor(h3);

    int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };

    foreach(int request in requests){

//循环给最小处理者提交请求，不同的数额，由不同权限处理者处理

h1.HandleRequest(request);

}

Console.Read();

}

++2B.18、解释器模式

++解释器模式的优缺点

++++优点1：解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。

++++缺点1：解释器模式会引起类膨胀。（每个语法都要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来了非常多的麻烦。）

++++缺点2：解释器模式采用递归调用方法。（每个非终结符表达式只关心与自己有关的表达式，每个表达式需要知道最终的结果，必须一层一层地剥茧，无论是面向过程的语言还是面向对象的语言，递归都是在必要条件下使用的，它导致调试非常复杂。如果要排查一个语法错误，要一个一个断点地调试下去，直到最小的语法单元。）

++++缺点3：效率问题。（解释器模式由于使用了大量的循环和递归，效率是一个不容忽略的问题，特别是用于解析复杂、冗长的语法时，效率是难以忍受的。）

++++使用场景1：重复发生的问题可以使用解释器模式。

++++使用场景2：一个简单语法需要解释的场景。（解释器模式一般用来解析比较标准的字符集。）

++++注意事项1：尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。

//立钻哥哥：interpreter解释器模式的代码实现

++++AbstractExpression（抽象表达式），声明一个抽象的解释操作，这个接口为抽象语法树中所有的节点所共享。

abstract class AbstractExpression{

public abstract void Interpret(Context context);

}

++++TerminalExpression（终结符表达式），实现与文法中的终结符相关联的解释操作。实现抽象表达式中所要求的接口，主要是一个interpret()方法。文法中每一个终结符都有一个具体终结表达式与之相对应。

class TerminalExpression : AbstractExpression{

    public override void Interpret(Context context){

Console.WriteLine(“立钻哥哥Print: 终端解释器”);

}

}

++++NonterminalExpression（非终结符表达式），为文法中的非终结符实现解释操作。对文法中每一条规则R1、R2......Rn都需要一个具体的非终结符表达式类。通过实现抽象表达式的interpret()方法实现解释操作。解释操作以递归方式调用上面所提到的代表R1、R2、......、Rn中各个符号的实例变量。

class NonterminalExpression : AbstractExpression{

    public override void Interpret(Context context){

Console.WriteLine(“立钻哥哥Print: 非终端解释器”);

}

}

++++Context，包含解释器之外的一些全局信息。

class Context{

    private string input;

    public string Input{

get{    return input;    }

set{    input = value;    }

}

    private string output;

    public string Output{

get{    return output;    }

set{    output = value;    }

}

}

++++客户端代码，构建表示该文法定义的语言中一个特定的句子的抽象语法树。调用解释操作。

static void Main(string[] args){

    Context context = new Context();

    List<AbstractExpression> list = new List<AbstractExpression>();

list.Add(new TerminalExpression());

list.Add(new NonterminalExpression());

list.Add(new TerminalExpression());

list.Add(new TerminalExpression());

    foreach(AbstractExpreesion exp in list){

exp.Interpret(context);

}

Console.Read();

}

++++结果显示：

终端解释器

非终端解释器

终端解释器

终端解释器

++2B.19、中介者模式

++中介者模式优缺点

++++优点A.1、减少了子类生成。（Mediator将原本分布于多个对象间的行为集中在一起。改变这些行为只需生成Meditator的子类即可。这样各个Colleague类可被重用。）

++++优点A.2、它将各Colleague解耦。（Mediator有利于各Colleague间的松耦合，可以独立的改变和复用各Colleague类和Mediator类。）

++++优点A.3、它简化了对象协议。（用Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。）

++++优点A.4、它对对象如何协作进行了抽象。（将中介作为一个独立的概念并将其封装在一个对象中，使我们将注意力从对象各自本身的行为转移到它们之间的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。）

++++缺点A.1、它使控制集中化。（中介者模式将交互的复杂性变为中介者的复杂性。因为中介者封装了协议，它可能变得比任一个Colleague都复杂。这可能使得中介者自身成为一个难于维护的庞然大物。）

++++中介者模式很容易在系统中应用，也很容易在系统中误用。（当系统出现了“多对多”交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理。）

++++优点B.1：Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator，由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统。

++++缺点B.1：由于ConcreteMediator控制了集中化，于是就把交互复杂性变味了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

++中介者模式的实际应用

++++立钻哥哥：中介者模式也叫做调停者模式，一个对象要和N多个对象交流，就像对象间的战争，很混乱。这是，需要加入一个中心，所有的类都和中心交流，中心说怎么处理就怎么处理。

++++应用1：机场调度中心。

++++应用2：MVC框架。（C（Controller）就是一个中介者，叫做前端控制器（Front Controller），它的作用就是把M（Model，业务逻辑）和V（View，视图）隔离开，协调M和V协同工作，把M运行的结果和V代表的视图融合成一个前端可展示的页面，减少M和V的依赖关系。）（MVC框架已经成为一个非常流行、成熟的开发框架，这也是中介者模式的优点的一个体现。）

++++应用3：媒体网关。

++++应用4：中介服务。

//立钻哥哥：Mediator中介者模式的代码实现

++++Colleague叫做抽象同事类，而ConcreteColleague是具体同事类，每个具体同事只知道自己的行为，而不了解其他同事类的情况，但它们却都认识中介者对象，Mediator是抽象中介者，定义了同事对象到中介者对象的接口，ConcreteMediator是具体中介者对象，实现抽象类的方法，它需要知道所有具体同事类，并从具体同事接收消息，向具体同事对象发出命令。

++++Mediator类（抽象中介者类）

abstract class Mediator{

//定义一个抽象的发送消息方法，得到同事对象和发送消息

    public abstract void Send(string message, Colleague colleague);

}

++++Colleague类（抽象同事类）

abstract class Colleague{

    protected Mediator mediator;

// 构造方法，得到中介者对象

    public Colleague(Mediator mediator){

this.mediator = mediator;

}

}

++++ConcreteMediator类（具体中介者类）

class ConcreteMediator : Mediator{

    private ConcreteColleague1 colleague1;

    private ConcreteColleague2 colleague2;

//需要了解所有的具体同事对象

    public ConcreteColleague1 Colleague1{

set{    colleague1 = value;    }

}

    public ConcreteColleague2 Colleague2{

set{    colleague2 = value;    }

}

//重写发送消息的方法，根据对象做出选择判断，通知对象

    public override void Send(string message, Colleague colleague){

if(colleague == colleague1){

colleague2.Notify(message);

}else{

colleague1.Notify(message);

}

}

}

++++ConcreteColleague1和ConcreteColleague2等各种同事对象。

class ConcreteColleague1 : Colleague{

    public ConcreteColleague1(Mediator mediator) : base(mediator){

}

//发送消息时通常是中介者发送出去的

    public void Send(string message){

mediator.Send(message, this);

}

    public void Notify(string message){

Console.WriteLine(“立钻哥哥Print: 同事1得到消息：” + message);

}

}

class ConcreteColleague2 : Colleague{

    public ConcreteColleague2(Mediator mediator) : base(mediator){

}

    public void Send(string message){

mediator.Send(message, this);

}

    public void Notify(string message){

Console.WriteLine(“立钻哥哥Print: 同事2得到信息：” + message);

}

}

++++客户端调用：

static void Main(string[] args){

    ConcreteMediator m = new ConcreteMediator();

//让两个具体同事类认识中介者对象

    ConcreteColleague1 c1 = new ConcreteColleague1(m);

    ConcreteColleague2 c2 = new ConcreteColleague2(m);

//让中介者认识各个各个具体同事类对象

m.Colleague1 = c1;

m.Colleague2 = c2;

c1.Send(“立钻哥哥：吃过饭了吗？”);

c2.Send(“立钻哥哥：没有呢，你打算请客？”);

Console.Read();

}

++2B.20、访问者模式

++访问者模式的优缺点

++++优点A.1、访问者模式使得易于增加新的操作。（访问者使得增加依赖于复杂对象结构的构件的操作变得容易了。仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。相反，如果每个功能都分散在多个类之上的话，定义新的操作时必须修改每一类。）

++++优点A.2、访问者集中相关的操作而分离无关的操作。（相关的行为不是分布在定义该对象结构的各个类上，而是集中在一个访问者中。无关行为却被分别放在它们各自的访问者子类中。这就既简化了这些元素的类，也简化了再这些访问者中定义的算法。所有与它的算法相关的数据结构都可以被隐藏在访问者中。）

++++缺点A.1、增加新的ConcreteElement类很困难.（Visitor模式使得难以增加新的Element的子类。每添加一个新的ConcreteElement都要在Vistor中添加一个新的抽象操作，并在每一个ConcretVisitor类中实现相应的操作。有时可以在Visitor中提供一个缺省的实现，这一实现可以被大多数的ConcreteVisitor继承，但这与其说是一个规律还不如说是一种例外。）（在应用访问者模式时考虑关键的问题是系统的哪个部分会经常变化，是作用于对象结构上的算法呢还是构成该结构的各个对象的类。如果老是有新的ConcreteElement类加入进来的话，Visitor类层次将变得难以维护。在这种情况下，直接在构成该结构的类中定义这些操作可能更容易一些。如果Element类层次时稳定的，而我们不断地增加操作或修改算法，访问者模式可以帮助我们管理这些改动。）

++++说明1：通过类层次进行访问。（一个迭代器（Iterator模式）可以通过调用节点对象的特定操作来遍历整个对象结构，同时访问这些对象。但是迭代器不能对具有不同元素类型的对象结构进行操作。）

++++说明2：累计状态。（当访问者访问对象结构中的每一个元素时，它可能会累积状态。如果没有访问者，这一状态将作为额外的参数传递给进行遍历的操作，或者定义为全局变量。）

++++说明3：破坏封装。（访问者方法假定ConcreteElement接口的功能足够强，足以让访问者进行它们的工作。结果是，该模式常常迫使我们提供访问元素内部状态的公共操作，这可能会破坏它的封装性。）

++++优点B.1：符合单一职责原则。（具体元素角色也就是Employee抽象类的两个子类负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。）

++++优点B.2：优秀的扩展性。（由于职责分开，继续增加对数据的操作是非常快捷的。）

++++优点B.3：灵活性非常高。

++++缺点B.1：具体元素对访问者公布细节。（访问者要访问一个类就必然要求这个类公布一些方法和数据，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的。）

++++缺点B.2：具体元素变更比较困难。（具体元素角色的增加、删除、修改都是比较困难的。）

++++缺点B.3：违背了依赖倒置原则。（访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是在面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。）

++++使用场景1：一个对象结构包含很多类对象，它们有不同的接口，而我们想对这些对象实施一些依赖于其具体类的操作。（也就是说用迭代器模式已经不能胜任的情景。）

++++使用场景2：需要对一个对象结构中的对象进行很多不同并且不相关的操作，而我们想避免让这些操作“污染”这些对象的类。

++++使用场景3：一定要考虑使用访问者模式的场景：业务规则要求遍历多个不同的对象。（这本身也是访问者模式出发点，迭代器模式只能访问同类或同接口的数据，而访问者模式是对迭代器模式的扩充，可以遍历不同的对象，然后执行不同的操作，也就是针对访问的对象不同，执行不同的操作。）

//立钻哥哥：Visitor访问者模式的代码实现

++++Visitor类，为该对象结构中ConcreteElement的每一个类声明一个Visit操作。

abstract class Visitor{

    public abstract void VisitConcreteElementA(ConcreteElementA concreteElementA);

    public abstract void VisitConcreteElementB(ConcreteElementB concreteElementB);

}

++++ConcreteVisitor1和ConcreteVisitor2类，具体访问者，实现每个由Visitor声明的操作。每个操作实现算法的一部分，而该算法片段乃是对应于结构中对象的类。

class ConcreteVisitor1 : Visitor{

    public override void VisitConcreteElementA(ConcreteElementA concreteElementA){

Console.WriteLine(“立钻哥哥Print: {0}被{1}访问”, concreteElementA.GetType().Name, this.GetType().Name);

}

    public override void VisitConcreteElementB(ConcreteElementB concreteElementB){

Console.WriteLine(“立钻哥哥Print: {0}被{1}访问”, concreteElementB.GetType().Name, this.GetType().Name);

}

}

class ConcreteVisitor2 : Visitor{

//代码与上类类似，省略....

}

++++Element类，定义一个Accept操作，它以一个访问者为参数：

abstract class Element{

public abstract void Accept(Visitor visitor);

}

++++ConcreteElementA和ConcreteElementB类，具体元素，实现Accept操作。

class ConcreteElementA : Element{

//充分利用双分派技术，实现处理与数据结构的分离。

    public override void Accept(Visitor visitor){

visitor.VisitConcreteElementA(this);

}

//其他的相关方法

    public void OperationA(){

}

}

class ConcreteElementB : Element{

    public override void Accept(Visitor visitor){

visitor.VisitConcreteElementB(this);

}

    public void OperationB(){

}

}

++++ObjectStructure类，能枚举它的元素，可以提供一个高层的接口以允许访问者访问它的元素。

class ObjectStructure{

    private List<Element> elements = new List<Element>();

    public void Attach(Element element){

elements.Add(element);

}

    public void Detach(Element element){

elements.Remove(element);

}

    public void Accept(Visitor visitor){

foreach(Element e in elements){

e.Accept(visitor);

}

}

}

++++客户端代码：

static void Main(string[] args){

    ObjectStructure o = new ObjectStructure();

o.Attach(new ConcreteElementA());

o.Attach(new ConcreteElementB());

    ConcreteVisitor1 v1 = new ConcreteVisitor1();

    ConcreteVisitor2 v2 = new ConcreteVisitor2();

o.Accept(v1);

o.Accept(v2);

Console.Read();

}

++2B.21、策略模式

//立钻哥哥：Strategy策略模式的代码实现

++++Strategy类，定义所有支持的算法的公共接口

//抽象算法类

abstract class Strategy{

//算法方法

    public abstract void AlgorithmInterface();

}

++++ConcreteStrategy，封装了具体的算法或行为，继承于Strategy

//具体算法A

class ConcreteStrategyA : Strategy{

//算法A实现方法

    public override void AlgorithmInterface(){

Console.WriteLine(“立钻哥哥Print: 算法A实现”);

}

}

//具体算法B

class ConcreteStrategyB : Strategy{

//算法B实现方法

    public override void AlgorithmInterface(){

Console.WriteLine(“立钻哥哥Print: 算法B实现”);

}

}

//具体算法C

class ConcreteStrategyC : Strategy{

//算法C实现方法

    public override void AlgorithmInterface(){

Console.WriteLine(“算法C实现”);

}

}

++++Context，用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。

//上下文

class Context{

    Strategy strategy;

//初始化时，传入具体的策略对象

    public Context(Strategy strategy){

this.strategy = strategy;

}

//上下文接口

//根据具体的策略对象，调用其算法的方法

    public void ContextInterface(){

strategy.AlgorithmInterface();

}

}

++++客户端代码：

static void Main(string[] args){

    Context context;

//由于实例化不同的策略，所以最终在调用context.ContextInterface();时，所获得的结果就不尽相同

context = new Context(new ConcreteStrategyA());

context.ContextInterface();

context = new Context(new ConcreteStrategyB());

context.ContextInterface();

context = new Context(new ConcreteStrategyC());

context.ContextInterface();

Console.Read();

}

++2B.22、备忘录模式

++备忘录模式的优缺点

++++立钻哥哥：由于备忘录模式有太多的变形和处理方式，每种方式都有它自己的优点和缺点，标准的备忘录模式很难在项目中遇到，基本上都有一些变换处理方式。因此，我们在使用备忘录模式时主要了解如何应用以及需要注意哪些事项就可以了。

++++使用场景1：需要保存和恢复数据的相关状态场景。

++++使用场景2：提供一个可回滚（rollback）的操作。

++++使用场景3：需要监控的副本场景中。

++++使用场景4：数据库连接的事务管理就是用的备忘录模式。

++++注意事项1：备忘录的生命期。（备忘录创建出来就要在“最近”的代码中使用，要主动管理它的生命周期，建立就要使用，不使用就要立刻删除其引用，等待垃圾回收器对它的回收处理。）

++++注意事项2：备忘录的性能。（不要在频繁建立备份的场景中使用备忘录模式（比如一个for循环中），原因有二：一是控制不了备忘录建立的对象数量；二是大对象的建立是要消耗资源的，系统的性能需要考虑。）

//立钻哥哥：Memento备忘录模式的代码实现

++++发起人（Originator）类：

class Originator{

//需要保存的属性，可能有多个

    private string state;

    public string State{

get{    return state;    }

set{    state = value;    }

}

//创建备忘录，将当前需要保存的信息导入并实例化出一个Memento对象

    public Memento CreateMemento(){

return (new Memento(state));

}

//恢复备忘录，将Memento导入并将相关数据恢复

    public void SetMemento(Memento memento){

state = memento.State;

}

//显示数据

    public void Show(){

Console.WriteLine(“立钻哥哥Print: State=” + state);

}

}

++++备忘录（Memento）类：

class Memento{

    private string state;

//构造方法，将相关数据导入

    public Memento(string state){

this.state = state;

}

//需要保存的数据属性，可以是多个

    public string State{

get{    return state;    }

}

}

++++管理者（Caretaker）类：

class Caretaker{

    private Memento memento;

//得到或设置备忘录

    public Memento Memento{

get{    return memento;    }

set{    memento = value;    }

}

}

++++客户端程序：

static void Main(string[] args){

    Originator o = new Originator();

//Originator初始状态，状态属性为“on”

o.State = “On”;

o.Show();

//保存状态时，由于有了很好的封装，可以隐藏Originator的实现细节

    Caretaker c = new Caretaker();

c.Memento = o.CreateMemento();

//Originator改变了状态属性为“Off”

o.State = “Off”;

o.Show();

//恢复原初始状态

o.SetMemento(c.Memento);

o.Show();

Console.Read();

}

++2B.23、迭代器模式

++迭代器模式的作用

++++作用1：它支持以不同的方式遍历一个聚合。（复杂的聚合可用多种方式进行遍历。）

++++作用2：迭代器简化了聚合的接口。（有了迭代器的遍历接口，聚合本身就不再需要类似的遍历接口了。这样就简化了聚合的接口。）

++++作用3：在同一个聚合上可以有多个遍历。（每个迭代器保持它自己的遍历状态。因此我们可以同时进行多个遍历。）

//立钻哥哥：Iterator迭代器模式的代码实现

++++Iterator迭代器抽象类

abstract class Iterator{

//用于定义得到开始对象、得到下一个对象、判断是否到结尾、当前对象等抽象方法，统一接口

    public abstract object First();

    public abstract object Next();

    public abstract bool IsDone();

    public abstract object CurrentItem();

}

++++Aggregate聚集抽象类

abstract class Aggregate{

//创建迭代器

public abstract Iterator CreateIterator();

}

++++ConcreteIterator具体迭代器类，继承Iterator

class ConcreteIterator : Iterator{

//定义了一个具体聚集对象

    private ConcreteAggregate aggregate;

    private int current = 0;

//初始化时将具体的聚集对象传入

    public ConcreteIterator(ConcreteAggregate aggregate){

this.aggregate = aggregate;

}

//得到聚集的第一个对象

    public override object First(){

return aggregate[0];

}

//得到聚集的下一个对象

    public override object Next(){

object ret = null;

current++;

if(current < aggregate.Count){

ret = aggregate[current];

}

        return ret;

}

//判断当前是否遍历到结尾，到结尾返回true

    public override bool IsDone(){

return current >= aggregate.Count ? true : false;

}

//返回当前的聚集对象

    public override object CurrentItem(){

return aggregate[current];

}

}

++++ConcreteAggregate具体聚集类，继承Aggregate

class ConcreteAggregate : Aggregate{

//声明一个List泛型变量，用于存放聚合对象，用ArrayList同样可以实现

    private List<object> items = new List<object>();

    public override Iterator CreateIterator(){

return new ConcreteIterator(this);

}

    public int Count{

//返回聚集总个数

get{    return items.Count;    }

}

//声明一个索引器

    public object this[int index]{

get{    return items[index];    }

set{    items.Insert(index, value);    }

}

}

++++客户端代码：

static void Main(string[] args){

//聚集对象（公交车）

    ConcreteAggregate a = new ConcreteAggregate();

//对象数组（乘客）

a[0] = “立钻哥哥”;

a[1] = “美女1”;

a[2] = “美女2”;

a[3] = “美女3”;

a[4] = “帅哥4”;

a[5] = “帅哥5”;

//声明迭代器对象（售票员）

    Iterator i = new ConcreteIterator(a);

//从第一个乘客开始

    object item = i.First();

    while(!i.IsDone()){

Console.WriteLine(“立钻哥哥Print: {0}请买车票！”, i.CurrentItem());

i.Next();

}

Console.Read();

}

++++运行结果：

立钻哥哥 请买车票

美女1 请买车票

美女2 请买车票

美女3 请买车票

帅哥1 请买车票

帅哥2 请买车票

++++立钻哥哥：当我们需要对聚集多种方式遍历时，可以考虑用迭代器模式。

#第三篇：框架编程篇

立钻哥哥推荐的拓展学习链接（Link_Url）