设计模式之工厂模式

    写在第一句的话：设计模式虽好，可不要贪杯哦，不要为了套设计模式而写设计模式，别把简单的问题复杂化。

    刚接触设计模式的时候，很疑惑，设计模式有什么用，又不能帮我写代码，但是时间长了，才知道，设计模式虽然不能帮助写代码，却有利于项目重构和扩展。

是什么？

    设计模式就是曾经写过代码的一批大佬们为了更好更方便的扩展和重构项目，利于发展的一种经验总结，所谓前人种树，后人乘凉，大佬们铺好了路，就看你走不走这条路。

原则是什么？

    所有的设计模式都遵循着几大原则，而原则都是围绕着如何快速扩展你的业务（代码），降低耦合度，减少工作任务开展的，用官方的话来讲，6大准则：

    单一职责原则(Single Responsibility Principle， SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

    里氏代换原则（Liskov Substitution Principle）：只要父类出现的地方子类就一定可以出现，而且替换为子类也不会出现任何异常或错误，使用者不需要知道是父类还是子类。但是返回来就不行了，有子类出现的地方，不一定能使用父类。

     依赖倒置原则（Dependence Inversion Principle）：高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。

    接口隔离原则（Interface Segregation Principle）：客户端不应该依赖它不需要的接口，类之间的依赖关系应该建立在最小的接口上。

    迪米特法则（Demeter Principle）：一个对象应该对其他对象有最少的了解

    开闭原则（Open Close Principle）：一个软件实体如类，模块和函数应该对扩展开放，对修改关闭，开闭原则也是其他五个原则的基石

    你说6大原则要背吗？我反正天生愚钝，背下来就忘，你说背下来有用吗，有，面试装逼绝对够用，那我自己背不下来，咋办，我是这样理解的，我既然背不下来，那我就用心去搞懂他。说白了6大原则都围绕高内聚，低耦合的思维，理解着种思路，再去理解看一遍。

有哪些设计模式？

    看图例这么多设计模式，刚接触的人基本都是吓死的，但是总结着看，设计模式分三类，抽象着看就是：

    创建型模式-->对象怎么来

    结构型模式-->对象和谁有关

    行为型模式-->对象与对象在干嘛

    对设计模式有个大概的概念了解了，下面我们就聊一下具体的设计模式：工厂模式。

工厂模式是什么？

    你看名字，工厂，主要是生产产品的，客户下单给工厂，工厂进行生产，而生产过程对客户来说是封闭的，不可见的。工厂模式就起到这种作用，你平时需要new来创建对象的过程，交给工厂类来实现。

    工厂模式细分优有三种：简单工厂模式，工厂方法模式，抽象工厂模式。 下面我给大家先讲讲简单工厂模式。

    在很久以前，有这么一家工厂，大家都亲切的称呼为浙江温州皮革厂，这家皮革工厂的老板黄先生，研究专门生产各种类型产品的包，男士包，女士包，钱包。

    以前呢，老板总是通过大音响在街头宣传自己的产品，然后别人打电话下单，出了新品别人也不知道，后来老板想起在上海的小叔子是写代码的，就让他帮忙写个商城来帮助自己做买卖。

    小叔子拿到需求后，看了一眼，这不就是自己刚学习的工厂模式么，于是小叔子画下了UML图。

    简单工厂模式:又称静态工厂方法模式，在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

    用人话说就是，我给工厂一个包包参数，工厂一看我有这个包，可以生产，那么我给返回这个包的实例对象。如果没有呢?可以返回报错或者空的，但是就是无法去生产自己没有的这个包。

    从UML来看，简单工厂模式

    工厂类（Factory）角色：担任这个角色的是简单工厂模式的核心，含有与应用紧密相关的商业逻辑。工厂类在客户端的直接调用下创建产品对象，它往往由一个具体Java类实现。

    抽象产品（AbstractProduct）角色：担任这个角色的类是由简单工厂模式所创建的对象的父类，或它们共同拥有的接口。抽象产品角色可以用一个Java接口或者Java抽象类实现。

    具体产品（Product）角色：简单工厂模式所创建的任何对象都是这个角色的实例，具体产品角色由一个具体Java类实现。

    那么简单工厂模式解决什么问题呢，请看下面例子:

    没有运用设计模式的时候，我需要拿到一个包的实例要怎么做。

public class   MenBags {

    private double price;

    private double size;

    private String color;

    public MenBags(){

        System.out.println("Create a MenBags");

    }

    public void product(){

         System.out.println("MenBags start product");

     }

}

public class WomenBags{

    private double price;

    private double size;

    private String color;

    public WomenBags(){

        System.out.println("Create a WomenBags");

    }

    public void product(){

         System.out.println("WomenBags start product");

     }

}

我要开始进行生产了:

public class Main {

    public static void main(String[] args) {

    //今天想做男士包 

    MenBags menBags = new MenBags();

     menBags.product();  

    }

}

public class Main {

    public static void main(String[] args) {

    //今天想做女士包 

    WomenBags womenBags = new WomenBags();

     womenBags.product();  

    }

}

这样做有什么问题没有，有的，代码结构乱，不容易维护，不管是男士包或者女式包都有相同的属性，那么为什么不进行抽象出一个公共的父类呢。

public abstract class Bag{

    abstract void product();

}

public class MenBags extends Bag{

    public MenBags(){

    System.out.println("Create a MenBags");

    }

    @Override

    public void product(){

         System.out.println("MenBags start product");

     }

}

public class WomenBags extends Bag{

    public WomenBags(){

        System.out.println("Create a WomenBags");

    }

    @Override

    public void product(){

     System.out.println("WomenBags start product");

         }

}

然后呢，因为是小工厂作坊式的，那么我再加个工厂来管理我的产品:

public class BagFactory() throws Exception{

    public statis Bag getBag(String bagType){

        if(“MenBags”.eques(bagType)){

            return  new  MenBags();

        }else if(“WomenBags ”.eques(bagType)){

            return  new  WomenBags();

        }else{

            throw new Exception();

                }

        }

}

好了，工厂建好了，我们只需要让客户知道他要什么产品就行了。假如黄老板的亲戚要个男包，好了，这个时候怎么操作呢。

public class Main {

        public static void main(String[] args) {

        //今天想做男士包 

        private final String menBags = “MenBags”;

        private final String womenBags= “WomenBags”;

        Bags bags = BagFactory.getBag(menBags);

         bags.product();  

        }

}

好了，简单工厂模式讲完了，是不是清晰了很多，这样做有什么好处呢?

优点:这样模块清晰化，每个部分都各司其职，分工明确，代码就实现最渐层意义上的“可维护”

缺点:

1。使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度

2。系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。所以说从工厂的角度来说简单工厂模式是不符合“开-闭”原则的。

3。简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

简单讲就是简单工厂模式不符合设计原则，但是却符合简单的小作坊小工厂模式，也就是产品少，创建对象少，逻辑不复杂。