DesignPattern设计模式-CSDN博客

本文链接：https://blog.csdn.net/xuqidashazi7/article/details/108594167

简述：提供一种创建对象的最佳方式。

在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

面向接口(抽象)编程？闻到内味了吗？7大设计原则中的依赖倒置原则、迪米特法则、接口隔离原则。

当然不止用到了一个原则，一般设计模式都是多个设计原则的集合体。

简单工厂模式#
简述：创建产品接口，需要产品时，利用工厂进行创建即可。

反例：

Copy
public class negtive {
/*=服务端========*/
interface Food{
void eat();
}

static class Noodles implements Food{
    @Override
    public void eat() {
        System.out.println("吃面条。。。。。");
    }
}

/=客户端===/
public static void main(String[] args) {
Food food01 = new Noodles();
food01.eat();
}
}
UML类图如下：

image-2020019529

这时候，产品来改需求来了，“哥，你先把刀放下。咱们现在这 Noodles改名了，得改个特牛逼的名字Spaghetti，让用户记住咱们这是西餐意大利面。”

这时候，因为你原有设计是上面的反例，你得能从修改服务端的源代码开始，再修改客户端源代码。以后再有改名这类事，你还要把刀拿出来放桌上给产品看。

这种设计过于脆弱，因为这样服务端源代码和客户端源代码是耦合的，改变会牵一发而动全身。

正例：

Copy
public class postive {

/*===============服务端======================*/
interface Food{
    void eat();
}

static class Spaghetti implements Food {
    @Override
    public void eat() {
        System.out.println("吃西餐面条。。。。。");
    }
}

static class FoodFactory {
    public Food getFood(int num){
        Food food =null;
        switch (num){
            case 1 :
                food = new Spaghetti();
        }
        return food;
    }
}

/*=================客户端===================*/
public static void main(String[] args) {
    FoodFactory foodFactory = new FoodFactory();
    Food food01 = foodFactory.getFood(1);
    food01.eat();
}

}
UML类图如下：

image-20200914191446305

通过这样一个正例，把创建对象的代码全交给服务端处理，将服务端代码和客户端代码进行了解耦。以后产品再找你聊天是不是可以暂时把刀收起来了？

这样做的好处，不只是服务端开发人员受益，当服务端代码修改时，客户端也不知道，也不需要知道。

这样的设计模式并不是十全十美的，任何一种设计模式都不会是十全十美的。只是根据业务逻辑在各方面进行取舍。

简单工厂模式的缺点：

客户必须记住工厂中常量和具体产品的映射关系。
一旦产品品种体量增大到一定程度，工厂类将变得非常臃肿。
最致命的缺陷，增加产品时，就要修改工厂类。违反开闭原则。
工厂方法模式#
简述：为了进行扩展，不违反开闭原则。

这里是基于简单工厂模式进行改进。

正例：

Copy
public class postive {
/*=服务端========*/
//-----------------------产品--------------------
interface Food{
void eat();
}

static class Spaghetti implements Food {
    @Override
    public void eat() {
        System.out.println("吃西餐面条。。。。。");
    }
}

//新增产品
static class Rice implements Food {
    @Override
    public void eat() {
        System.out.println("吃米饭。。。。。");
    }
}

//--------------------------工厂-----------------------
 interface FoodFactory {
     Food getFood();
}

static class SpaghettiFactory implements FoodFactory{

    @Override
    public Food getFood() {
        return new Spaghetti();
    }
}

//新增产品工厂
static class RiceFactory implements FoodFactory{

    @Override
    public Food getFood() {
        return new Rice();
    }
}

/*=================客户端===================*/
public static void main(String[] args) {
     FoodFactory foodFactory = new  SpaghettiFactory();
     Food food01 = foodFactory.getFood();
    food01.eat();
}

}
UML类图如下：

针对简单工厂违反开闭原则的这一缺陷，工厂方法模式进行优化。可以看到此时再去增加产品，不再需要修改工厂类，而是增加相应的产品类和工厂类即可。这是符合开闭原则的。

这里就会有聪明的小问号有很多朋友了：

如果源代码作者修改相关工厂类的类名，那这时候调用工厂类的客户端代码就需要修改了，这不如简单工厂呢？
首先这里要明确一个概念，工厂类在实际使用中，是相当于接口类的，接口类一般不允许进行修改（非必须），工厂类作者有责任，有义务保证工厂类的类名是稳定的，也就是说，工厂类是比产品类更加稳定的。

既然使我们后面自己扩展的Rice类，为什么不直接实例化它，直接使用。我们就是作者，为什么不能直接使用？
这里需要扩展一下，有时候一个产品类并不是孤立的，它和其他类一起组成一个服务框架。

下面增加一些类：

Copy
/*=服务端========*/
//------------------------产品质检流程-----------------------、

static class QualityInspection {

    public void checking(FoodFactory foodFactory){
        System.out.println("我是人肉质检员。。。。。准备开吃 -_- ");
        Food food = foodFactory.getFood();
        food.eat();
    }
}
/*=================客户端===================*/
public static void main(String[] args) {
    FoodFactory foodFactory01 = new  SpaghettiFactory();
    FoodFactory foodFactory02 = new  RiceFactory();

    QualityInspection inspection = new QualityInspection();
    inspection.checking(foodFactory02);
    inspection.checking(foodFactory01);

image-20200914175016710

UML类图如下：

image-20200914204539759

这时候，如果Rice没有他的工厂类，甚至都没办法参加质检，那还怎么卖？

所以编写工厂类并不只是单纯为了实例化某些产品类，而是能让配套服务通过工厂接口，得以调用工厂创建产品实例。

有的小朋友大大的眼睛里还有疑惑：那为什么QualityInspection的checking方法不直接调用Food接口再进行产品的实例化呢？

这时候回到简单工厂模式，产品类不同于工厂类，它是善变的，它会随着需求的变化而变化，这时候，直接依赖产品类的各种方法，将需要被修改，违反开闭原则。这是死路，小朋友别杠了。哈哈哈。

当然，工厂方法模式也是有缺陷的：

当业务需要的类型变多，目前只有食物，当产生饮料，日用品等类别时，我们又要创建新的工厂来实现，造成代码重复臃肿。
抽象工厂模式#
针对工厂方法模式的缺陷，抽象工厂模式将进行改进，一个工厂负责创建一个产品簇的对象。

关于产品簇：是指多个存在内在联系的或者存在逻辑关系的产品。

image-20200914221314906
简述：在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

正例：

Copy
public class postive {
/*=服务端========*/

//-----------------------产品--------------------
/*----------------螺丝---------------------*/
interface Screw{
    void createScrew();
}

static class Screw_06 implements Screw {
    @Override
    public void createScrew() {
        System.out.println("create Screw_06 666666。。。。。");
    }
}

static class Screw_08 implements Screw {
    @Override
    public void createScrew() {
        System.out.println("create Screw_08 8888888。。。。。");
    }
}
/*----------------螺母---------------------*/
interface Nut{
    void createNut();
}

static class Nut_06 implements Nut {
    @Override
    public void createNut() {
        System.out.println("create Nut_06 666666。。。。。");
    }
}

static class Nut_08 implements Nut {
    @Override
    public void createNut() {
        System.out.println("create Nut_08 8888888。。。。。");
    }
}


//--------------------------工厂-----------------------
interface ComponentsFactory {
    Screw getScrew();
    Nut getNut();
}
/*----------------6号工厂---------------------*/
static class Factory_666 implements ComponentsFactory {

    @Override
    public Screw getScrew() {
        return new Screw_06();
    }

    @Override
    public Nut getNut() {
        return new Nut_06();
    }
}

/*----------------8号工厂---------------------*/
static class Factory_888 implements ComponentsFactory {

    @Override
    public Screw getScrew() {
        return new Screw_08();
    }

    @Override
    public Nut getNut() {
        return new Nut_08();
    }
}

//------------------------产品质检流程-----------------------、
static class QualityInspection {

    public void checking(ComponentsFactory Factory){
        System.out.println("我是人肉质检员。。。。。等待产出零件 -_- ");
        Screw screw = Factory.getScrew();
        Nut nut = Factory.getNut();
        screw.createScrew();
        nut.createNut();
        System.out.println("开始质检.......");
        System.out.println("      ");
    }
}

/*=================客户端===================*/
public static void main(String[] args) {
    ComponentsFactory Factory01 = new   Factory_666();
    ComponentsFactory Factory02 = new   Factory_888();

    QualityInspection inspection = new QualityInspection();
    inspection.checking(Factory01);
    inspection.checking(Factory02);
}

}
UML类图如下：

image-20200914225519685

可以看到，如果在需要进行一种N号螺丝或者螺母的扩展，只需要增加一个实现N号螺丝或者螺母接口的产品类，利用一个新增N号工厂进行创建即可。

可以看到，抽象工厂仍然保持着简单工厂模式和工厂方法模式的优点：

服务端代码和客户端代码是低耦合的。（简单工厂模式）
所有这一切动作都是新增，不是修改，符合开闭原则。
还新增了一个特有的优点：

抽象工厂有效减少了工厂的数量，一个工厂就生产同一个产品簇的产品。
这下产品来改需求，是不是还可以笑嘻嘻跟他聊会天了？

再次强调，一个抽象工厂负责创建同一个产品簇的对象。而产品簇是指多个存在内在联系的或者存在逻辑关系的产品。也就是6号工厂只生产6号的零部件，不负责生产8号零部件。不能不同产品簇的产品混合到一个工厂中进行生产。

缺陷：当增加产品簇时（增加6 、 8号螺帽的生产），这时候就要修改以前工厂（6 、 8号工厂）的源代码了。

总结就是：