举个栗子，现在巧克力和香子兰两个人肚子饿了，要吃饭。吃饭的过程有三个步骤：

1.吃配菜；

2.吃主食；

3.喝饮料；

虽然吃饭步骤一样，可是两个人吃的东西却不同。巧克力配菜要吃西红柿炒鸡蛋，主食要吃馒头，饮料要喝可乐；而香子兰要吃麻婆豆腐，米饭和牛奶。

如果用程序表示的话，可以看出二者使用相同的验算流程，且实现的内容不一样。一般情况下我们会分别给二者写一套代码，这样做没有什么问题。可是如果后续开发需要添加新的功能呢，比如说红豆，时雨也要吃饭饭。或者她们想改变下吃饭的流程，先吃主食再吃配菜呢？是不是要为每套代码做出修改？显而易见这样的实现不太好，那么有没有一种好的实现方法呢？

答案就是使用模板方法模式（Template）

偷来的结构图_(:з」∠)_

1.定义一个算法的流程，即是很明确的定义算法的每一个步骤，并写在父类的方法中，而每一个步骤都可以是一个方法的调用。

2.某些步骤由子类完成。

代码实现

算法定义类：

由一个主方法和三个步骤方法组成，主方法不可重写，步骤方法必须在子类实现：

abstract class IEat
{
    public void Eat()
    {
        EatDishes();
        EatStaple();
        Drink();
    }

    protected abstract void EatDishes();
    protected abstract void EatStaple();
    protected abstract void Drink();
}

算法步骤的实现类：

巧克力：

class ChocolatEat : IEat
{
    protected override void EatDishes()
    {
        Console.WriteLine("配菜：西红柿炒鸡蛋");
    }

    protected override void EatStaple()
    {
        Console.WriteLine("主食：馒头");
    }
    protected override void Drink()
    {
        Console.WriteLine("饮料：可乐");
    }
}

香子兰：

class VinillaEat : IEat
{
    protected override void EatDishes()
    {
        Console.WriteLine("配菜：麻婆豆腐");
    }

    protected override void EatStaple()
    {
        Console.WriteLine("主食：米饭");
    }
    protected override void Drink()
    {
        Console.WriteLine("饮料：牛奶");
    }
}

在Main中调用：

static void Main(string[] args)
{
    ChocolatEat chocolat = new ChocolatEat();
    VinillaEat vinilla = new VinillaEat();

    Console.WriteLine("巧克力吃了：");
    chocolat.Eat();

    Console.WriteLine("-------------");
    Console.WriteLine("香子兰吃了：");
    vinilla.Eat();
}

结果：

结论

模板方法模式将可能出现重复的“算法流程”从子类提升到父类中，减少重复的发生，并且也开放子类参与算法中各个步骤的执行或优化。但如果“算法流程”开放太多的步骤，并要求子类必须全部重新实现的话，反而会造成实现的困难，也不容易维护。

【设计模式】05 – 模板方法模式最先出现在初晴神社。

外观模式有点黑箱的意思，即把内部细节封装起来，对外只有简单的接口方便调用。比如一台电视机内部有显像系统，声音系统，电子系统等等，通过这些系统协调工作才组成了一台功能正常的电视机。而当我们想看电视时，并不用关系这些系统怎么配合，只需要接通电源，打开电视机就可以看了。

所以，外观模式的重点在于，它能将系统内部的互动细节隐藏以来，并提供简单方便的接口，之后客户端只需要通过这个接口，就可以操作一个复杂系统并让他们顺利运行。

惯例盗张结构图_(:з」∠)_

上图是使用外观模式之后的，如果未使用状态模式大概长这样：

看起来貌似也没多大问题，不过当Client多了可就不一样了：

这下调用结果相当混乱，很容易就晕了。。

可以看到整个系统分为三个部分：

• 客户端，用户。从原本需要操作多个子系统的情况，改为只需要面对一个整合后的界面。
• 统一对外的界面。整合所有子系统的接口及功能，并提供接口供Client使用。<br>同时接收客户端的信息后，将信息传送给子系统。
• 子系统。原本会由不同的Client来操作，改为只会由内部系统互相使用。

代码演示

SusSystem

为了方便演示每个系统都只有启动和关闭方法

class SubSystem1
{
    public void Start()
    {
        Console.WriteLine("SubSystem1已启动");
    }

    public void Close()
    {
        Console.WriteLine("SubSystem1已关闭");
    }
}

class SubSystem2
{
    public void Start()
    {
        Console.WriteLine("SubSystem2已启动");
    }

    public void Close()
    {
        Console.WriteLine("SubSystem2已关闭");
    }
}

class SubSystem3
{
    public void Start()
    {
        Console.WriteLine("SubSystem3已启动");
    }

    public void Close()
    {
        Console.WriteLine("SubSystem3已关闭");
    }
}

Facade

Facade持有了以上单个子系统的引用，并定义了总开关方法

class Facade
{
    private SubSystem1 sub1;
    private SubSystem2 sub2;
    private SubSystem3 sub3;

    public Facade()
    {
        sub1 = new SubSystem1();
        sub2 = new SubSystem2();
        sub3 = new SubSystem3();
    }

    public void StartAllSubSystem()
    {
        sub1.Start();
        sub2.Start();
        sub3.Start();
    }

    public void CloseAllSubSystem()
    {
        sub1.Close();
        sub2.Close();
        sub3.Close();
    }
}

Client

这里我们将Main方法当做Client，只需要一条命令就可以实现打开或关闭所有子系统的方法。

static void Main(string[] args)
{
    Facade facade = new Facade();
    facade.StartAllSubSystem();
    Console.WriteLine();
    facade.CloseAllSubSystem();
}

运行结果：

使用外观模式的优缺点

将复杂的子系统沟通交给单一的一个类负责，并提供单一界面给客户端使用，使客户端减少对系统的耦合度。

使用状态模式可以将Client类单一化，方便的调用一个接口，而不必关心这个接口功能背后是一堆子系统怎么实现的。

减少了Client类不必要的类引用及功能整合（只需要引用一个Facade就够了），增加了Client类被复用的机会。

由此可见，外观模式很利于分工开发。在分工配合时，开发者只需要了解对方负责系统的Facade接口类，不必更进一步关心对方的实现方式。

缺点即是由于将所有子系统集中在Facade接口中，最终会导致Facade接口类过于庞大和难以维护。

这种情况下可以重构Facade接口类，将功能相近的子系统进行整合，以减少内部系统的依赖性，或是整合其他设计模式来减少接口类大小。

【设计模式】04 – 外观模式最先出现在初晴神社。

状态模式，顾名思义，在于状态以及切换。比较常用的就是状态机，一个游戏角色在空闲，移动，攻击等状态相互切换时，就可以用状态模式。从一种行为转化为另一种行为的过程都在游戏内部实现，玩家不需要理解这个转化过程。而且无论怎么转化，玩家都是控制的该角色，并不会因为其内部的转变而有所差异。

另外虽然游戏角色会从空闲切换到攻击等状态，它的“表现行为”会有所变化，但是对于客户端来说，并不会因为这样的变化，而改变对它的“操作方法”的方式，也就是从开发角度说，这个对象对外界的对应方式不会有任何改变。但是对象的内部确实是会通过“更换状态类对象”的方式来进行状态的转换。

来看下状态模式的结构图：

（懒得画图了，自己找了个。与后续代码有些不同，不过整体结构是一样的）

其中：

[successbox title=”Context”]状态的拥有者，可以制定相关的接口，让外界能够得知状态的改变或通过操作让状态改变。[/successbox]

[infobox title=”State”]状态接口类，规范Context在特定状态下要表现的行为。[/infobox]

[infobox title=”StartState等”]具体状态类，实现Context在特定状态下该有的行为。比如角色空闲状态，攻击状态等。[/infobox]

代码实现

Context：

class Context
{
    private IState state;  // 代表当前状态

    // 更改状态
    public void SetState(IState state)
    {
        this.state = state;
    }

    // 状态行为
    public void Run()
    {
        if (state != null)
        {

            state.Handle();
        }
    }
}

IState

抽象类，通过构造方法传入Context，以便后续操作中使用。并定义了一个抽象方法，使其在子类中实现。

abstract class IState
{
    protected Context context;

    public IState(Context context)
    {
        this.context = context;
    }

    public abstract void Handle();
}

3个State

class StateA : IState
{
    public StateA(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateA");
        context.SetState(new StateB(context));
    }
}

class StateB : IState
{
    public StateB(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateB");
        context.SetState(new StateC(context));
    }
}

class StateC : IState
{
    public StateC(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateC");
        context.SetState(new StateA(context));
    }
}

上述三个子类都实现了父类的抽象方法，用来表示在各自状态下的行为。这里为了演示，只做了最简单的切换状态功能。

Context类中提供了SetState方法用来让外界切换状态，而这个“外界”也可以是另一个State。所以实现上，状态的切换可以有一下两种方式：

• 交由Context类本身，按条件在各状态之间切换；
• 产生Context类对象时，马上指定初始状态给Context对象，而后在后续执行过程中的状态转换则交由State对象负责，Context对象不再介入。

测试代码：

static void Main(string[] args)
{
    Context context = new Context();
    context.SetState(new StateA(context));

    context.Run();
    context.Run();
    context.Run();
    context.Run();
}

结果如下：

结论

使用状态模式的优点：

1.减少错误的发生并降低维护难度；

不再使用switch来判断状态，在后续更新维护时如果需要新的功能（状态），直接从IState派生就可以了，符合了开闭原则。

2.状态执行环境单一化；

与每一个状态有关的对象及操作都被实现在一个场景状态下，符合单一职责原则。

3.项目之间可以共享，增强可复用性。

参考资料：《设计模式与游戏完美开发》

【设计模式】03 – 状态模式最先出现在初晴神社。

中介者模式又叫做调停者模式，顾名思义跟房产中介是类似的。拿房产中介来说，现在房子买家和房子卖家非常多，如果任由房子买家和房子卖家自由交易，则会导致不同的买家和卖家之间有很多交互，一个买家会和多个卖家进行交涉，同样的一个卖家也会和多个买家进行交涉。如果在买房的过程中出现纠纷问题，则很难进行解决。就如下图所示一样。

可以看出不同买家和卖家进行了很多错综复杂的交互，不利于发展。

• 单一系统引入太多其他系统的功能，不利于单一系统的转换和维护；
• 单一系统被过多的系统所依赖，不利于接口的更改，容易牵一发动全身；
• 因为需提供给其他系统操作，系统的接口可能会过于庞大，不容易维护；

迪米特原则，尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。

迪米特原则同样适用于本场景，我们可以引入第三者也就是中介。它的出现不需要买家和卖家进行直接交涉，而是通过中介而进行交涉。并且也不容易出现买卖家之间纠纷，因为有中介者房产中介进行第三方监督。如下图所示：

可以看到图中的关系清晰了很多。

同理在软件开发中，如果为了减少对象之间的交互和耦合，符合迪米特原则，那么就可以使用中介者模式。

【设计模式】02 – 中介者模式最先出现在初晴神社。

• 某个类只能有一个实例；
• 它必须自行创建这个实例；
• 它必须自行向整个系统提供这个实例。

• 单例模式的类只提供私有的构造函数，
• 类定义中含有一个该类的静态私有对象，
• 该类提供了一个静态的公有的函数用于创建或获取它本身的静态私有对象。

优缺点

写法1（只适用于单线程环境）

由于单例模式只有一个实例，即没有继承，所以一般将其设为sealed。

同时把构造方法设为私有，防止从外部创建，我们可以定义一个静态的实例，在需要的时候创建该实例。

代码如下：

namespace _01_单例模式
{
    sealed class Singleton1
    {
        private static Singleton1 instance;
        private static Singleton1 Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new Singleton1();
                }
                return instance;
            }
        }

        private Singleton1()
        {

        }
    }
}

这种写法比较简单，只有在instance为空时才会创建实例，避免了重复创建。

缺点：该代码在单线程下可以正常工作，但在多线程环境下可能会出现问题。如果存在两个线程同时运行到if (instance == null) 并且instance还未创建，那么两个线程都会创建一个实例，这样就不再满足单例模式要求了。

写法2（可以在多线程中正常工作）

为了解决写法1的缺点，需要加上一个同步锁。写法如下：

namespace _01_单例模式
{
    sealed class Singleton2
    {
        private static object syncObj = new object();

        private static Singleton2 instance;
        private static Singleton2 Instance
        {
            get
            {
                if (instance == null)
                {
                    lock (syncObj)
                    {
                        if (instance == null)
                        {
                            instance = new Singleton2();
                        }
                    }
                }
                return instance;
            }
        }

        private Singleton2()
        {

        }
    }
}

在这个类里面创建了一个object专门用与互斥锁判断，同时用了两个if语句。第一个语句限制只有在instance为空时进行互斥判断，提高了效率。

而第二个if，假如有两个线程同时运行到了lock (syncObj) ，其中一个线程向下执行，创建instance。创建之后另一个线程继续运行，如果没有第二个if，第二个线程还会创建instance，不符合要求。

该类解决了多线程的问题，不过运用了两个if，依然比较复杂。

【推荐】写法3（利用静态构造方法）

其实C#中又一个方法能够确保只调用一次，即静态构造方法。所以可以利用这个特点实现单例模式。

代码如下：

namespace _01_单例模式
{
    sealed class Singleton3
    {
        private static Singleton3 instance = new Singleton3();

        public static Singleton3 Instance
        {
            get
            {
                return instance;
            }
        }

        private Singleton3()
        {

        }
    }
}

由于C#是在调用静态构造方法时初始化静态变量，在运行时能确保只调用一次静态构造方法，这样就能保证只初始化一次instance。

不过该方式依然有个小缺点：C#中的静态构造方法并非程序员控制，而是系统自动调用。假如Singleton3中有个静态方法，当我们第一次调用该静态方法时，instance就会被创建。但我们的本意希望调用Singleton3.Instance时创建。所以这个方式可能会过早的创建实例，降低内存使用效率。

【推荐】写法4（按需创建）

为了优化写法3，我们可以额外利用一个类。写法如下：

namespace _01_单例模式
{
    sealed class Singleton4
    {
        public static Singleton4 Instance
        {
            get
            {
                return Nested.instance;
            }
        }

        class Nested
        {
            internal static readonly Singleton4 instance = new Singleton4();

            static Nested()
            {

            }
        }

        private Singleton4()
        {

        }
    }
}

在Singleton4内部定义了一个私有类型Nested，当我们第一次调用Singleton4.Instance时，会自动调用Nested的静态构造方法创建instance。如果不调用Singleton4.Instance，就不会触发.Net运行时调用Nested，也不会创建实例，这样就做到了按需创建。

【设计模式】01 – 单例模式最先出现在初晴神社。

01 – 单例模式

02 – 中介者模式

03 – 状态模式

04 – 外观模式

【设计模式】学习笔记最先出现在初晴神社。