C#设计模式总结

原文地址：http://www.cnblogs.com/zhili/p/SingletonPatterm.html

1、引言

　　通过这段时间对设计模式的学习，本身的感触仍是不少的，由于我如今在写代码的时候，常常会想一想这里能不能用什么设计模式来进行重构。因此，学完设计模式以后，感受它会慢慢地影响到你写代码的思惟方式。这里对设计模式作一个总结，一来能够对全部设计模式进行一个梳理，二来能够作一个索引来帮助你们收藏。

　　PS: 其实，很早以前我就看过全部的设计模式了，可是并无写博客，可是不久就很快忘记了，也没有起到什么做用，此次以博客的形式总结出来，发现效果仍是很明显的，由于经过这种总结的方式，我对它理解更深入了，也记住的更牢靠了，也影响了本身平时实现功能的思惟。因此，我鼓励你们能够经过作笔记的方式来把本身学到的东西进行梳理，这样相信能够理解更深，更好，我也会一直写下来，以后打算写WCF一系列文章。

　　其实WCF内容很早也看过了，而且博客园也有不少前辈写的很好，可是，我以为我仍是须要本身总结，由于只有这样，知识才是本身的，别人写的多好，你看了以后，其实仍是别人了，因此鼓励你们几点（对于这几点，也是对本身的一个提醒）：

1. 要动手实战别人博客中的例子；
2. 实现以后进行总结，能够写博客也能够本身记录云笔记等；
3. 想一想能不能进行扩展，进行触类旁通。

　　系列导航：

　　C#设计模式(1)——单例模式

      C#设计模式(2)——简单工厂模式

　　C#设计模式(3)——工厂方法模式

　　C#设计模式(4)——抽象工厂模式

　　C#设计模式(5)——建造者模式（Builder Pattern）

　　C#设计模式(6)——原型模式（Prototype Pattern）

　　C#设计模式(7)——适配器模式（Adapter Pattern）

　　C#设计模式(8)——桥接模式（Bridge Pattern） 

　　C#设计模式(9)——装饰者模式（Decorator Pattern）

　　C#设计模式(10)——组合模式（Composite Pattern）

　　C#设计模式(11)——外观模式（Facade Pattern）

　　C#设计模式(12)——享元模式（Flyweight Pattern）

　　C#设计模式(13)——代理模式（Proxy Pattern）

　　C#设计模式(14)——模板方法模式（Template Method）

　　C#设计模式(15)——命令模式（Command Pattern）

　　C#设计模式(16)——迭代器模式（Iterator Pattern）

　　C#设计模式(17)——观察者模式（Observer Pattern）

　　C#设计模式(18)——中介者模式（Mediator Pattern）

　　C#设计模式(19)——状态者模式（State Pattern）

　　C#设计模式(20)——策略者模式（Stragety Pattern）

　　C#设计模式(21)——责任链模式

　　C#设计模式(22)——访问者模式（Vistor Pattern）

　　C#设计模式(23)——备忘录模式（Memento Pattern）

2、 设计原则

　　使用设计模式的根本缘由是适应变化，提升代码复用率，使软件更具备可维护性和可扩展性。而且，在进行设计的时候，也须要遵循如下几个原则：单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。下面就分别介绍了每种设计原则。

2.1 单一职责原则

　　就一个类而言，应该只有一个引发它变化的缘由。若是一个类承担的职责过多，就等于把这些职责耦合在一块儿，一个职责的变化可能会影响到其余的职责，另外，把多个职责耦合在一块儿，也会影响复用性。

2.2 开闭原则(Open-Closed Principle)

　　开闭原则即OCP（Open-Closed Principle缩写）原则，该原则强调的是：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化时，要经过添加新的代码来加强现有类型的行为，而不是修改原有的代码。

　　符合开闭原则的最好方式是提供一个固有的接口，而后让全部可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。

2.3 里氏代替原则(Liskov Substitution Principle)

　　Liskov Substitution Principle,LSP（里氏代替原则）指的是子类必须替换掉它们的父类型。也就是说，在软件开发过程当中，子类替换父类后，程序的行为是同样的。只有当子类替换掉父类后，此时软件的功能不受影响时，父类才能真正地被复用，而子类也能够在父类的基础上添加新的行为。为了就来看看违反了LSP原则的例子，具体代码以下所示：

 public class Rectangle
    {
        public virtual long Width { get; set; }
        public virtual long Height { get; set; }
    }
    // 正方形
    public class Square : Rectangle
    {
        public override long Height
        {
            get
            {
                return base.Height;
            }
            set
            {
                base.Height = value;
                base.Width = value;
            }
        }

        public override long Width
        {
            get
            {
                return base.Width;
            }
            set
            {
                base.Width = value;
                base.Height = value;
            }
        }
    }
 class Test
    {
        public void Resize(Rectangle r)
        {
            while (r.Height >= r.Width)
            {
                r.Width += 1;
            }
        }
        var r = new Square() { Width = 10, Height = 10 };
         new Test().Resize(r);
     }

　　上面的设计，正如上面注释的同样，在执行SmartTest的resize方法时，若是传入的是长方形对象，当高度大于宽度时，会自动增长宽度直到超出高度。可是若是传入的是正方形对象，则会陷入死循环。此时根本缘由是，矩形不能做为正方形的父类，既然出现了问题，能够进行重构，使它们俩都继承于四边形类。重构后的代码以下所示：

 // 四边形
    public abstract class Quadrangle
    {
        public virtual long Width { get; set; }
        public virtual long Height { get; set; }
    }
    // 矩形
    public class Rectangle : Quadrangle
    {
        public override long Height { get; set; }

        public override long Width { get; set; }
       
    }
    // 正方形
    public class Square : Quadrangle
    {
        public long _side;

        public Square(long side)
        {
            _side = side;
        }
    }
 class Test
    {
        public void Resize(Quadrangle r)
        {
            while (r.Height >= r.Width)
            {
                r.Width += 1;
            }
        }


        static void Main(string[] args)
        {
            var s = new Square(10);

            new Test().Resize(s);
        }
    }

2.4 依赖倒置原则

　　依赖倒置（Dependence Inversion Principle, DIP）原则指的是抽象不该该依赖于细节，细节应该依赖于抽象，也就是提出的 “面向接口编程，而不是面向实现编程”。这样能够下降客户与具体实现的耦合。

2.5 接口隔离原则

　　接口隔离原则（Interface Segregation Principle, ISP）指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每一个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。

2.6 合成复用原则

　　合成复用原则（Composite Reuse Principle, CRP）就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象经过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽可能使用合成/聚合，尽可能不要使用继承。

　　要使用好合成复用原则，首先须要区分"Has—A"和“Is—A”的关系。

　　“Is—A”是指一个类是另外一个类的“一种”，是属于的关系，而“Has—A”则不一样，它表示某一个角色具备某一项责任。致使错误的使用继承而不是聚合的常见的缘由是错误地把“Has—A”当成“Is—A”.例如：

实际上，雇员、经历、学生描述的是一种角色，好比一我的是“经理”必然是“雇员”。在上面的设计中，一我的没法同时拥有多个角色，是“雇员”就不能再是“学生”了，这显然不合理，由于如今不少在职研究生，即便雇员也是学生。

　　上面的设计的错误源于把“角色”的等级结构与“人”的等级结构混淆起来了，误把“Has—A”看成"Is—A"。具体的解决方法就是抽象出一个角色类：

2.7 迪米特法则

　　迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其余对象有尽量少的了解。也就是说，一个模块或对象应尽可能少的与其余实体之间发生相互做用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。

　　关于迪米特法则其余的一些表述有：只与你直接的朋友们通讯；不要跟“陌生人”说话。

　　外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。

3、建立型模式

 　　建立型模式就是用来建立对象的模式，抽象了实例化的过程。全部的建立型模式都有两个共同点。第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被建立和组织的。建立型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。

• 单例模式：解决的是实例化对象的个数的问题，好比抽象工厂中的工厂、对象池等，除了Singleton以外，其余建立型模式解决的都是 new 所带来的耦合关系。
• 抽象工厂：建立一系列相互依赖对象，并能在运行时改变系列。
• 工厂方法：建立单个对象，在Abstract Factory有使用到。
• 原型模式：经过拷贝原型来建立新的对象。

　　工厂方法，抽象工厂, 建造者都须要一个额外的工厂类来负责实例化“一个对象”，而Prototype则是经过原型（一个特殊的工厂类）来克隆“易变对象”。

　　下面详细介绍下它们。

3.1  单例模式

 　　单例模式指的是确保某一个类只有一个实例，并提供一个全局访问点。解决的是实体对象个数的问题，而其余的建造者模式都是解决new所带来的耦合关系问题。其实现要点有：

• 类只有一个实例。问：如何保证呢？答：经过私有构造函数来保证类外部不能对类进行实例化
• 提供一个全局的访问点。问：如何实现呢？答：建立一个返回该类对象的静态方法

　　单例模式的结构图以下所示：

 

 

3.2 工厂方法模式

 　　工厂方法模式指的是定义一个建立对象的工厂接口，由其子类决定要实例化的类，将实际建立工做推迟到子类中。它强调的是”单个对象“的变化。其实现要点有：

• 定义一个工厂接口。问：如何实现呢？答：声明一个工厂抽象类
• 由其具体子类建立对象。问：如何去实现呢？答：建立派生于工厂抽象类，即由具体工厂去建立具体产品，既然要建立产品，天然须要产品抽象类和具体产品类了。

　　其具体的UML结构图以下所示：

　　在工厂方法模式中，工厂类与具体产品类具备平行的等级结构，它们之间是一一对应关系。

3.3 抽象工厂模式

 　　抽象工厂模式指的是提供一个建立一系列相关或相互依赖对象的接口，使得客户端能够在没必要指定产品的具体类型的状况下，建立多个产品族中的产品对象，强调的是”系列对象“的变化。其实现要点有：

• 提供一系列对象的接口。问：如何去实现呢？答：提供多个产品的抽象接口
• 建立多个产品族中的多个产品对象。问：如何作到呢？答：每一个具体工厂建立一个产品族中的多个产品对象，多个具体工厂就能够建立多个产品族中的多个对象了。

　　具体的UML结构图以下所示：

　　

 

3.4 建造者模式

 　　建造者模式指的是将一个产品的内部表示与产品的构造过程分割开来，从而可使一个建造过程生成具体不一样的内部表示的产品对象。强调的是产品的构造过程。其实现要点有：

• 将产品的内部表示与产品的构造过程分割开来。问：如何把它们分割开呢？答：不要把产品的构造过程放在产品类中，而是由建造者类来负责构造过程，产品的内部表示放在产品类中，这样不就分割开了嘛。

　　具体的UML结构图以下所示：

　　

3.5 原型工厂模式

 　　原型模式指的是经过给出一个原型对象来指明所要建立的对象类型，而后用复制的方法来建立出更多的同类型对象。其实现要点有：

• 给出一个原型对象。问：如何办到呢？答：很简单嘛，直接给出一个原型类就行了。
• 经过复制的方法来建立同类型对象。问：又是如何实现呢？答：.NET能够直接调用MemberwiseClone方法来实现浅拷贝

　　具体的UML结构图以下所示：

4、结构型模式

 　　结构型模式，顾名思义讨论的是类和对象的结构 ，主要用来处理类或对象的组合。它包括两种类型，一是类结构型模式，指的是采用继承机制来组合接口或实现；二是对象结构型模式，指的是经过组合对象的方式来实现新的功能。它包括适配器模式、桥接模式、装饰者模式、组合模式、外观模式、享元模式和代理模式。

• 适配器模式注重转换接口，将不吻合的接口适配对接 
• 桥接模式注重分离接口与其实现，支持多维度变化 
• 组合模式注重统一接口，将“一对多”的关系转化为“一对一”的关系 
• 装饰者模式注重稳定接口，在此前提下为对象扩展功能 
• 外观模式注重简化接口，简化组件系统与外部客户程序的依赖关系 
• 享元模式注重保留接口，在内部使用共享技术对对象存储进行优化 
• 代理模式注重假借接口，增长间接层来实现灵活控制

4.1 适配器模式

 　　适配器模式意在转换接口，它可以使本来不能再一块儿工做的两个类一块儿工做，因此常常用来在类库的复用、代码迁移等方面。例如DataAdapter类就应用了适配器模式。适配器模式包括类适配器模式和对象适配器模式，具体结构以下图所示，左边是类适配器模式，右边是对象适配器模式。

4.2 桥接模式

 　　桥接模式旨在将抽象化与实现化解耦，使得二者能够独立地变化。意思就是说，桥接模式把原来基类的实现化细节再进一步进行抽象，构造到一个实现化的结构中，而后再把原来的基类改形成一个抽象化的等级结构，这样就能够实现系统在多个维度的独立变化，桥接模式的结构图以下所示。

4.3 装饰者模式

 　　装饰者模式又称包装（Wrapper）模式，它能够动态地给一个对象添加一些额外的功能，装饰者模式较继承生成子类的方式更加灵活。虽然装饰者模式可以动态地将职责附加到对象上，但它也会形成产生一些细小的对象，增长了系统的复杂度。具体的结构图以下所示。

4.4 组合模式

 　　组合模式又称为部分—总体模式。组合模式将对象组合成树形结构，用来表示总体与部分的关系。组合模式使得客户端将单个对象和组合对象同等对待。如在.NET中WinForm中的控件，TextBox、Label等简单控件继承与Control类，同时GroupBox这样的组合控件也是继承于Control类。组合模式的具体结构图以下所示。

4.5 外观模式

　　在系统中，客户端常常须要与多个子系统进行交互，这样致使客户端会随着子系统的变化而变化，此时可使用外观模式把客户端与各个子系统解耦。外观模式指的是为子系统中的一组接口提供一个一致的门面，它提供了一个高层接口，这个接口使子系统更加容易使用。如电信的客户专员，你可让客户专员来完成冲话费，修改套餐等业务，而不须要本身去与各个子系统进行交互。具体类结构图以下所示：

4.6 享元模式

 　　在系统中，如何咱们须要重复使用某个对象时，此时若是重复地使用new操做符来建立这个对象的话，这对系统资源是一个极大的浪费，既然每次使用的都是同一个对象，为何不能对其共享呢？这也是享元模式出现的缘由。

　　享元模式运用共享的技术有效地支持细粒度的对象，使其进行共享。在.NET类库中，String类的实现就使用了享元模式，String类采用字符串驻留池的来使字符串进行共享。更多内容参考博文：http://www.cnblogs.com/artech/archive/2010/11/25/internedstring.html。享元模式的具体结构图以下所示。

4.7 代理模式

 　　在系统开发中，有些对象因为网络或其余的障碍，以致于不能直接对其访问，此时能够经过一个代理对象来实现对目标对象的访问。如.NET中的调用Web服务等操做。

　　代理模式指的是给某一个对象提供一个代理，并由代理对象控制对原对象的访问。具体的结构图以下所示。

　　

　　注：外观模式、适配器模式和代理模式区别？

　　解答：这三个模式的相同之处是，它们都是做为客户端与真实被使用的类或系统之间的一个中间层，起到让客户端间接调用真实类的做用，不一样之处在于，所应用的场合和意图不一样。

　　代理模式与外观模式主要区别在于，代理对象没法直接访问对象，只能由代理对象提供访问，而外观对象提供对各个子系统简化访问调用接口，而适配器模式则不须要虚构一个代理者，目的是复用原有的接口。外观模式是定义新的接口，而适配器则是复用一个原有的接口。

　　另外，它们应用设计的不一样阶段，外观模式用于设计的前期，由于系统须要前期就须要依赖于外观，而适配器应用于设计完成以后，当发现设计完成的类没法协同工做时，能够采用适配器模式。然而不少状况下在设计初期就要考虑适配器模式的使用，如涉及到大量第三方应用接口的状况；代理模式是模式完成后，想以服务的方式提供给其余客户端进行调用，此时其余客户端可使用代理模式来对模块进行访问。

　　总之，代理模式提供与真实类一致的接口，旨在用来代理类来访问真实的类，外观模式旨在简化接口，适配器模式旨在转换接口。

5、行为型模式

 　　行为型模式是对在不一样对象之间划分责任和算法的抽象化。行为模式不只仅关于类和对象，还关于它们之间的相互做用。行为型模式又分为类的行为模式和对象的行为模式两种。

• 类的行为模式——使用继承关系在几个类之间分配行为。
• 对象的行为模式——使用对象聚合的方式来分配行为。

　　行为型模式包括11种模式：模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、状态模式、策略模式、责任链模式、访问者模式、解释器模式和备忘录模式。

• 模板方法模式：封装算法结构，定义算法骨架，支持算法子步骤变化。
• 命令模式：注重将请求封装为对象，支持请求的变化，经过将一组行为抽象为对象，实现行为请求者和行为实现者之间的解耦。
• 迭代器模式：注重封装特定领域变化，支持集合的变化，屏蔽集合对象内部复杂结构，提供客户程序对它的透明遍历。
• 观察者模式：注重封装对象通知，支持通讯对象的变化，实现对象状态改变，通知依赖它的对象并更新。
• 中介者模式：注重封装对象间的交互，经过封装一系列对象之间的复杂交互，使他们不须要显式相互引用，实现解耦。
• 状态模式：注重封装与状态相关的行为，支持状态的变化，经过封装对象状态，从而在其内部状态改变时改变它的行为。
• 策略模式：注重封装算法，支持算法的变化，经过封装一系列算法，从而能够随时独立于客户替换算法。
• 责任链模式：注重封装对象责任，支持责任的变化，经过动态构建职责链，实现事务处理。
• 访问者模式：注重封装对象操做变化，支持在运行时为类结构添加新的操做，在类层次结构中，在不改变各种的前提下定义做用于这些类实例的新的操做。
• 备忘录模式：注重封装对象状态变化，支持状态保存、恢复。
• 解释器模式：注重封装特定领域变化，支持领域问题的频繁变化，将特定领域的问题表达为某种语法规则下的句子，而后构建一个解释器来解释这样的句子，从而达到解决问题的目的。

5.1 模板方法模式

 　　在现实生活中，有论文模板，简历模板等。在现实生活中，模板的概念是给定必定的格式，而后其余全部使用模板的人能够根据本身的需求去实现它。一样，模板方法也是这样的。

　　模板方法模式是在一个抽象类中定义一个操做中的算法骨架，而将一些具体步骤实现延迟到子类中去实现。模板方法使得子类能够不改变算法结构的前提下，从新定义算法的特定步骤，从而达到复用代码的效果。具体的结构图以下所示。

以生活中作菜为例子实现的模板方法结构图

5.2 命令模式

 　　命令模式属于对象的行为模式，命令模式把一个请求或操做封装到一个对象中，经过对命令的抽象化来使得发出命令的责任和执行命令的责任分隔开。命令模式的实现能够提供命令的撤销和恢复功能。具体的结构图以下所示。

5.3 迭代器模式

 　　迭代器模式是针对集合对象而生的，对于集合对象而言，必然涉及到集合元素的添加删除操做，也确定支持遍历集合元素的操做，此时若是把遍历操做也放在集合对象的话，集合对象就承担太多的责任了，此时能够进行责任分离，把集合的遍历放在另外一个对象中，这个对象就是迭代器对象。

　　迭代器模式提供了一种方法来顺序访问一个集合对象中各个元素，而又无需暴露该对象的内部表示，这样既能够作到不暴露集合的内部结构，又可让外部代码透明地访问集合内部元素。具体的结构图以下所示。

5.4 观察者模式

 　　在现实生活中，到处可见观察者模式，例如，微信中的订阅号，订阅博客和QQ微博中关注好友，这些都属于观察者模式的应用。

　　观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态发生变化时，会通知全部观察者对象，使它们可以自动更新本身的行为。具体结构图以下所示：

5.5 中介者模式

 　　在现实生活中，有不少中介者模式的身影，例如QQ游戏平台，聊天室、QQ群和短信平台，这些都是中介者模式在现实生活中的应用。

　　中介者模式，定义了一个中介对象来封装一系列对象之间的交互关系。中介者使各个对象之间不须要显式地相互引用，从而使耦合性下降，并且能够独立地改变它们之间的交互行为。具体的结构图以下所示：

5.6 状态模式

 　　每一个对象都有其对应的状态，而每一个状态又对应一些相应的行为，若是某个对象有多个状态时，那么就会对应不少的行为。那么对这些状态的判断和根据状态完成的行为，就会致使多重条件语句，而且若是添加一种新的状态时，须要更改以前现有的代码。这样的设计显然违背了开闭原则，状态模式正是用来解决这样的问题的。

　　状态模式——容许一个对象在其内部状态改变时自动改变其行为，对象看起来就像是改变了它的类。具体的结构图以下所示：

5.7 策略模式

 　　在现实生活中，中国的所得税，分为企业所得税、外商投资企业或外商企业所得税和我的所得税，针对于这3种所得税，每种所计算的方式不一样，我的所得税有我的所得税的计算方式，而企业所得税有其对应计算方式。若是不采用策略模式来实现这样一个需求的话，咱们会定义一个所得税类，该类有一个属性来标识所得税的类型，而且有一个计算税收的CalculateTax()方法，在该方法体内须要对税收类型进行判断，经过if-else语句来针对不一样的税收类型来计算其所得税。这样的实现确实能够解决这个场景，可是这样的设计不利于扩展，若是系统后期须要增长一种所得税时，此时不得不回去修改CalculateTax方法来多添加一个判断语句，这样明白违背了“开放——封闭”原则。此时，咱们能够考虑使用策略模式来解决这个问题，既然税收方法是这个场景中的变化部分，此时天然能够想到对税收方法进行抽象，这也是策略模式实现的精髓所在。

　　策略模式是对算法的包装，是把使用算法的责任和算法自己分割开，委派给不一样的对象负责。策略模式一般把一系列的算法包装到一系列的策略类里面。用一句话慨括策略模式就是——“将每一个算法封装到不一样的策略类中，使得它们能够互换”。下面是策略模式的结构图：

　　

5.8 责任链模式

 　　在现实生活中，有不少请求并非一我的说了就算的，例如面试时的工资，低于1万的薪水可能技术经理就能够决定了，可是1万~1万5的薪水可能技术经理就没这个权利批准，可能须要请求技术总监的批准。

　　责任链模式——某个请求须要多个对象进行处理，从而避免请求的发送者和接收之间的耦合关系。将这些对象连成一条链子，并沿着这条链子传递该请求，直到有对象处理它为止。具体结构图以下所示：

5.9 访问者模式

 　　访问者模式是封装一些施加于某种数据结构之上的操做。一旦这些操做须要修改的话，接受这个操做的数据结构则能够保存不变。访问者模式适用于数据结构相对稳定的系统， 它把数据结构和做用于数据结构之上的操做之间的耦合度下降，使得操做集合能够相对自由地改变。具体结构图以下所示：

5.10 备忘录模式

 　　生活中的手机通信录备忘录，操做系统备份点，数据库备份等都是备忘录模式的应用。备忘录模式是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象以外保存这个状态，这样之后就能够把该对象恢复到原先的状态。具体的结构图以下所示：

5.11 解释器模式

 　　解释器模式是一个比较少用的模式，因此我本身也没有对该模式进行深刻研究，在生活中，英汉词典的做用就是实现英文和中文互译，这就是解释器模式的应用。

　　解释器模式是给定一种语言，定义它文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释器语言中的句子。具体的结构图以下所示：

6、总结

 　　23种设计模式，其实前辈们总结出来解决问题的方式，它们追求的宗旨仍是保证系统的低耦合高内聚，指导它们的原则无非就是封装变化，责任单一，面向接口编程等设计原则。以后，我会继续分享本身WCF的学习过程，尽管博客园中有不少WCF系列，以前以为不必写，以为会用就好了，可是不写，总感受知识不是本身的，感受没有深刻，因此仍是想写这样一个系列，但愿各位博友后面多多支持。

　　PS： 不少论坛都看到初学者问，WCF如今还有没有必要深刻学之类的问题，由于他们以为这些技术可能会过期，说不定到时候微软又推出了一个新的SOA的实现方案了，那岂不是白花时间深刻学了，因此就以为不必深刻去学，知道用就能够了。对于这个问题，我以前也有这样一样的感受，可是如今我以为，尽管WCF技术可能会被替换，但深刻了解一门技术，重点不是知道一些更高深API的调用啊，而是了解它的实现机制和思惟方式，即便后面这个技术被替代了，其背后机制也确定是类似的。因此深刻了解了一个技术，你就会感受新的技术熟悉，对其感受放松。而且，你深刻了解完一门技术以后，你面试时也敢说你很好掌握了这门技术，而不至于说平时使用的不少，一旦深刻问时殊不知道背后实现原理。这也是我要写WCF系列的缘由。但愿这点意见对一些初学者有帮助。