23种设计模式

Posted 2021-01-19 menbo

1.简单工厂模式

简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导。

模式定义
简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

模式优缺点

• 简单工厂模式的优点

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

• 简单工厂模式的缺点

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

模式适用环境
在以下情况下可以使用简单工厂模式：
工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

Fruit：抽象产品

public interface Fruit {
    public void getFruit();
}

orange:具体产品角色

public class Orange implements Fruit{

    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
        System.out.println("获得橘子");
    }

}

apple:具体产品

public class Apple implements Fruit{

    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
        System.out.println("获得苹果");
    }
  
}

工厂类：

public class  SimpleFactory {
     public static Fruit getFruit(String type) throws Exception{
    if(type.equalsIgnoreCase("orange")){
        return new Orange();
    }else if(type.equals("apple")){
        return new Apple();
    }else{
        return null;
    }
     
     }
}

测试类：

public class MainClass {
  public static void main(String[] args) throws Exception {
    Fruit apple = SimpleFactory.getFruit("apple");
    Fruit orange = SimpleFactory.getFruit("Orange");
    apple.getFruit();
    orange.getFruit();
 }
}

运行结果：

 2.工厂方法模式：

    工厂方法模式是简单工厂模式的一个延伸，它解决的仍然是软件设计中与创建对象有关的问题。它可以更好的处理客户的需求变化。在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。
    工厂方式法模式（Factory Method），定义了一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。

参与者
抽象产品角色（Product）：定义产品的接口
具体产品角色（ConcreteProduct） ：实现接口Product的具体产品类
抽象工厂角色（Creator） ：声明工厂方法（FactoryMethod），返回一个产品
真实的工厂（ConcreteCreator）：实现FactoryMethod工厂方法，由客户调用，返回一个产品的实例

Fruit：抽象产品

orange:具体产品角色

apple:具体产品

工厂类：FruitFactory

public interface FruitFactory {
    public Fruit getFruit();
}

真实工厂：AppleFactory

public class AppleFactory implements FruitFactory {
    @Override
    public Fruit getFruit() {
        // TODO Auto-generated method stub
        return new Apple();
    }
}

 

PearFactory:

public class PearFactory implements FruitFactory{
    @Override
    public Fruit getFruit() {
        // TODO Auto-generated method stub
        return new Pear();
    }
}

测试：

public class MainClass {
  public static void main(String[] args) throws Exception {
   FruitFactory  appleFactory= new AppleFactory();
  Apple apple = (Apple) appleFactory.getFruit();
  apple.getFruit();
  
  FruitFactory pearFactory = new PearFactory();
  Pear pear = (Pear) pearFactory.getFruit();
  pear.getFruit();
 }
}

运行结果：

工厂方法模式的优点
在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。

工厂方法模式的缺点
在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

 3.抽象工厂模式

意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

主要解决：主要解决接口选择的问题。

何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

如何解决：在一个产品族里面，定义多个产品。每个具体的工厂负责一个产品族。抽象工厂的返回值为最高级抽象产品。

关键代码：在一个工厂里聚合多个同类产品（在同一个产品族中）。

 

抽象产品：
public interface Fruit {
    public void getFruit();
}

apple:
public abstract class Apple implements Fruit{
    public abstract void getFruit();
}

orange:
public abstract class Orange implements Fruit{
   public abstract void getFruit();
}

northapple:
public class NorthApple extends Apple{
    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
        System.out.println("获得北方苹果");
    }
 
}

southapple:
public class SouthApple extends Apple {
    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
      System.out.println("获得南方苹果");
    }
}

northorange:
public class NorthOrange extends Orange {
    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
        System.out.println("获得北方橘子");
    }
}
southorange:
public class SouthOrange extends Orange {
    @Override
    public void getFruit() {
        // TODO Auto-generated method stub
        System.out.println("获得南方橘子");
    }
}

抽象工厂：
public interface FruitFactory {
   public Fruit getApple();
   public Fruit getOrange();
}
//生产北方产品
public class NorthFactory implements FruitFactory{
    @Override
    public Fruit getApple() {
        // TODO Auto-generated method stub
        return new NorthApple();
        }
    @Override
    public Fruit getOrange() {
        // TODO Auto-generated method stub
        return new NorthOrange();
    }
}
//生产南方产品
public class SouthFactory implements FruitFactory {
    @Override
    public Fruit getApple() {
        // TODO Auto-generated method stub
        return new SouthApple();
    }
    @Override
    public Fruit getOrange() {
        // TODO Auto-generated method stub
        return new SouthOrange();
    }
}

测试：
 public static void main(String[] args) throws Exception {
     FruitFactory southFactory = new SouthFactory();
     SouthApple  apple= (SouthApple) southFactory.getApple();
     apple.getFruit();
     SouthOrange orange = (SouthOrange) southFactory.getOrange();
     orange.getFruit();
     
     FruitFactory northFactory = new NorthFactory();
     NorthApple apple2 = (NorthApple) northFactory.getApple();
     apple2.getFruit();
     NorthOrange orange2 = (NorthOrange) northFactory.getOrange();
     orange2.getFruit();
 }

运行结果：

 抽象工程模式的优点：

封装性，每个产品的实现类不是高层模块要关系的，要关心的是什么？是接口，是抽象，它不关心对象是如何创建出来，这由谁负责呢？工厂类，只要知道工厂类是谁，我就能创建出一个需要的对象，省时省力，优秀设计就应该如此。

产品族内的约束为非公开状态。例如生产男女比例的问题上，猜想女娲娘娘肯定有自己的打算，不能让女盛男衰，否则女性的优点不就体现不出来了吗？那在抽象工厂模式，就应该有这样的一个约束：每生产1个女性，就同时生产出1.2个男性，这样的生产过程对调用工厂类的高层模块来说是透明的，它不需要知道这个约束，我就是要一个黄色女性产品就可以了，具体的产品族内的约束是在工厂内实现的。

缺点：

  抽象工厂模式的最大缺点就是产品族扩展非常困难，为什么这么说呢？我们以通用代码为例，如果要增加一个产品C，也就是说有产品家族由原来的2个，增加到3个，看看我们的程序有多大改动吧！抽象类AbstractCreator要增加一个方法createProductC()，然后，两个实现类都要修改，想想看，这在项目中的话，还这么让人活！严重违反了开闭原则，而且我们一直说明抽象类和接口是一个契约，改变契约，所有与契约有关系的代码都要修改，这段代码叫什么？叫“有毒代码”，——只要这段代码有关系，就可能产生侵害的危险！

使用场景：

 抽象工厂模式的使用场景定义非常简单：一个对象族（或是一组没有任何关系的对象）都有相同的约束，则可以使用抽象工厂模式，什么意思呢？例如一个文本编辑器和一个图片处理器，都是软件实体，但是linux下的文本编辑器和WINDOWS下的文本编辑器虽然功能和界面都相同，但是代码实现是不同的，图片处理器也是类似情况，也就是具有了共同的约束条件：操作系统类型，于是我们可以使用抽象工厂模式，产生不同操作系统下的编辑器和图片处理器。