前言：笔者在最开始写程序的时候经常会遇到一种情况，例如更改一个字段、或者添加一种小功能，就要把原来写过的东西几乎废弃掉，或者更改大量以前写过的代码。又或者自己写的东西时间久了再去回顾，完全找不到到时为什么这么写的头绪，如果遇到了Bug更是无法快速定位在哪里小范围出现的问题。如果你也经常遇到这种问题，就说明你现阶段非常需要学习下设计模式了。

在网上经常说的设计模式有23种，也有一些更多的设计模式，无非也是从这些设计模式中变种而来。如果让笔者来形容什么是设计模式，我认为设计模式是：一种思想，一种模式，一种套路，一种解决问题的高效策略。

举个生活中的列子：你需要从家去公园，虽然都是从A点到B点，但目的是着急取东西，你会用代步工具快速到达，但如果仅仅是打发时间，完全可以散步去。用代步工具和散步本身没有绝对的对错，只是根据当时的需求采取的策略。设计模式这种思想，就是根据你当时的需求给你提供最高效的策略。

有说的不正确或者不准确的地方欢迎留言指正

有什么有趣的写作技巧或者想法欢迎大家给我留言，大家的帮助是我写下去最有效的动力

在上次的【话大】设计模式之简单工厂笔者有提到过还有跟多优化的地方，下面笔者跟大家聊一聊简单工程的优化版 ------【工厂方法】

现在我们的策划大佬来了新的需求，说海澜我们现在需要增加“产品”，原来的“产品”不好，全部去掉，换成10个新的，而且每个“产品”在生产之前要有一些检测机制。按照简单工厂的套路，我们知道，在工厂类Switch中把原来的产品的case删掉，然后添加10个新的case，然后在对应的语句块中添加需要的检测机制。设计模式之面向对象七大原则我们知道，这种方式违背了单一原则和开闭原则，违背单一原则是因为过多的涉及其他产品的生产，虽然都是生产产品。违背开闭原则是因为，在一个工厂类中有许多产品的产生，不管是增加产品或者是对单一产品的修改都有可能造成其他产品的干扰。所以我要对他们进行再次的分离，再次的封装。

public interface IProduct{}

public class Computer : IProduct{}

public class IPhone : IProduct{}

public class Mac : IProduct{}

public class IPad : IProduct{}

public interface IFactory
{
    IProduct CreatProduct();
}

public class FactoryComputer : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(Computer);
    }
}

public class FactoryIPhone : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPhone);
    }
}

public class FactoryMac : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(Mac);
    }
}

public class FactoryIPad : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPad);
    }
}

最终使用的时候变成了这个样子

    public void ExampleFactoryMethod()
    {
        IFactory factory = new FactoryComputer();
        IProduct computer = factory.CreatProduct();

        factory = new FactoryIPhone();
        IProduct iPhone = factory.CreatProduct();

        factory = new FactoryMac();
        IProduct mac = factory.CreatProduct();

        factory = new FactoryIPad();
        IProduct iPad = factory.CreatProduct();
    }

现在让我们和简单工厂对比一下

现在直观的看，代码量增加了，而且对产品的选择由下端工厂类又转交给上端业务逻辑层了。但笔者认为对于版本迭代来说，这种牺牲是值得的，理由有一下几点

• 产品的增加和删除不会影响到其他产品的产出
• 单个产品逻辑修改只需要在对应的工厂类修改即可
• 职责更加明确，方便后续的维护和Bug定位
• 更符合开闭原则

为什么说更符合开闭原则呢？因为如果在在版本迭代的时候，在原有产品的基础上添加检测等机制，可以用如下写法，完全不会涉及到原来类的源码。

public class FactoryIPad : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPad);
    }
}


public class FactoryIPad_Extend : FactoryIPad
{
    public override IProduct CreatProduct()
    {
        /*
         * 检测一
         * 检测二
         * 检测三
         */
        return base.CreatProduct();
    }
}

工厂方法(Factory Method),定义了一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

笔者说过，运用哪种设计模式没有绝对的对错，设计模式是：一种思想，一种模式，一种套路，一种解决问题的高效策略，如果真的后续不会有什么改动，那就怎么简单怎么写就好了。当然工厂还有另一种写法，那就是【抽象工厂】，笔者后续会提到~