23种设计模式

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下的文本编辑器虽然功能和界面都相同，但是代码实现是不同的，图片处理器也是类似情况，也就是具有了共同的约束条件：操作系统类型，于是我们可以使用抽象工厂模式，产生不同操作系统下的编辑器和图片处理器。

4.原型模型

所谓原型模式就是用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。

区分两个概念：深拷贝、浅拷贝。

      浅拷贝：使用一个已知实例对新创建实例的成员变量逐个赋值，这个方式被称为浅拷贝。（对象内部有非基本类型变量只复制其引用）

     深拷贝：当一个类的拷贝构造方法，不仅要复制对象的所有非引用成员变量值，还要为引用类型的成员变量创建新的实例，并且初始化为形式参数实例值。（对象内部有非基本类型变量还要复制该变量）

浅拷贝：

public class Person implements Cloneable{
    private String name;
    private String sex;
    private List<String> friends = new ArrayList<String>();
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String getSex() {
        return sex;
    }
    public void setSex(String sex) {
        this.sex = sex;
    }
    
    public List<String> getFriends() {
        return friends;
    }
    public void setFriends(List<String> friends) {
        this.friends = friends;
    }
    @Override
    public String toString() {
        return "Person [name=" + name + ", sex=" + sex + ", friends=" + friends + "]";
    }
    public Person clone(){
        try {
            return (Person) super.clone();
        } catch (CloneNotSupportedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
            return null;
        }    
    }
}

Test:
public class MainClass {
     public static void main(String[] args) {
        Person person1 = new Person();
        person1.setName("zhangsan");
        person1.setSex("男");
        Person person2 = person1.clone();
        person1.setName("张三");
        List<String> friends = new ArrayList<String>();
        friends.add("wangwu");
        friends.add("zhangliu");
        person1.setFriends(friends);
        System.out.println(person1);
        System.out.println(person2);
    }
}

测试结果：

Person [name=张三, sex=男, friends=[wangwu, zhangliu]]
Person [name=zhangsan, sex=男, friends=[wangwu, zhangliu]]

深拷贝：

public Person clone(){
        try {
            Person pserson = (Person) super.clone();
            List<String> list = new ArrayList<String>();
            for(String friend:this.friends){
                list.add(friend);
            }
            return pserson;
        } catch (CloneNotSupportedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
            return null;
        }    
    }

测试结果：

Person [name=张三, sex=男, friends=[wangwu, zhangliu]]
Person [name=zhangsan, sex=男, friends=[]]

 5.建造者模式

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 
何时使用：一些基本部件不会变，而其组合经常变化的时候。

模式讲解：
1. 指挥者（Director）直接和客户（Client）进行需求沟通；
2. 沟通后指挥者将客户创建产品的需求划分为各个部件的建造请求（Builder）；
3. 将各个部件的建造请求委派到具体的建造者（ConcreteBuilder）；
4. 各个具体建造者负责进行产品部件的构建；
5. 最终构建成具体产品（Product）。

public class House {
     private String floor;
     private String top;
     private String wall;
    public String getFloor() {
        return floor;
    }
    public void setFloor(String floor) {
        this.floor = floor;
    }
    public String getTop() {
        return top;
    }
    public void setTop(String top) {
        this.top = top;
    }
    public String getWall() {
        return wall;
    }
    public void setWall(String wall) {
        this.wall = wall;
    }
     
}
builder:
public interface HouseBuilder {
    public House getHouse();
    public void makeFloor();
    public void makeTop();
    public void makeWall();
}
concreteBuilder:
public class GongYuBuilder implements HouseBuilder{
  private House house = new House();
    @Override
    public House getHouse() {
        // TODO Auto-generated method stub
        return house;
    }

    @Override
    public void makeFloor() {
        // TODO Auto-generated method stub
        house.setFloor("公寓-floor");
    }

    @Override
    public void makeTop() {
        // TODO Auto-generated method stub
        house.setTop("公寓-top");
    }

    @Override
    public void makeWall() {
        // TODO Auto-generated method stub
        house.setWall("公寓-wall");
    }
   
}
concreteBuilder:
public class PingFangBuilder implements HouseBuilder{
  private House house = new House();
    @Override
    public House getHouse() {
        // TODO Auto-generated method stub
        return house;
    }

    @Override
    public void makeFloor() {
        // TODO Auto-generated method stub
        house.setFloor("平房-floor");
    }

    @Override
    public void makeTop() {
        // TODO Auto-generated method stub
        house.setTop("平房-top");
    }

    @Override
    public void makeWall() {
        // TODO Auto-generated method stub
        house.setWall("平房-wall");
    }

}
Director:
public class HouseDirector {
   public void makeHouse(HouseBuilder builder){
       builder.makeFloor();
       builder.makeTop();
       builder.makeWall();
   }
}
测试：
public class MainClass {
    public static void main(String[] args) {
        HouseBuilder houseBuilder = new GongYuBuilder();
        HouseDirector director = new HouseDirector();
        director.makeHouse(houseBuilder);
        House house = houseBuilder.getHouse();
        System.out.println(house.getFloor());
        System.out.println(house.getTop());
        System.out.println(house.getWall());
    }
}

运行结果：

6.装饰者模式

意图：

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

设计原则：

1). 多用组合，少用继承。

利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。

2). 类应设计的对扩展开放，对修改关闭。

要点：

1)． 装饰者和被装饰对象有相同的超类型。

2)． 可以用一个或多个装饰者包装一个对象。

3)． 装饰者可以在所委托被装饰者的行为之前或之后，加上自己的行为，以达到特定的目的。

4)． 对象可以在任何时候被装饰，所以可以在运行时动态的，不限量的用你喜欢的装饰者来装饰对象。

5)． 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配，而不是获得其行为。

6)． 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为，做到“半透明”装饰者。

7)． 适配器模式的用意是改变对象的接口而不一定改变对象的性能，而装饰模式的用意是保持接口并增加对象的职责。

角色及职责：

结构图：

public interface Car {
     public void show();
     public void run();
}

public class RunCar implements Car {
    @Override
    public void show() {
        // TODO Auto-generated method stub
        this.run();
    }

    @Override
    public void run() {
        // TODO Auto-generated method stub
        System.out.println("可以跑");
    }
}

public abstract class CarDecorator implements Car{
     private Car car;

    public Car getCar() {
        return car;
    }

    public void setCar(Car car) {
        this.car = car;
    }
     
    public CarDecorator(Car car){
        this.car = car;
    }
    public abstract void show();
}

public class FlyCarDecorator extends CarDecorator{

    public FlyCarDecorator(Car car) {
        super(car);
        // TODO Auto-generated constructor stub
    }
    public void show(){
        this.getCar().show();
        this.fly();
    }
    public void fly(){
        System.out.println("可以飞");
    }
    @Override
    public void run() {
        // TODO Auto-generated method stub
        
    }
}

public class SwimCarDecorator extends CarDecorator {

    public SwimCarDecorator(Car car) {
        super(car);
        // TODO Auto-generated constructor stub
    }

    @Override
    public void show() {
        // TODO Auto-generated method stub
       this.getCar().show();
       this.swim();
    }
    public void swim(){
        System.out.println("可以游");
    }

    @Override
    public void run() {
        // TODO Auto-generated method stub
        
    }
}

public class MainClass {
    public static void main(String[] args) {
        Car car = new RunCar();
        car.show();
        System.out.println("----------------");
        CarDecorator flyCar = new FlyCarDecorator(car);
        flyCar.show();
        System.out.println("----------------");
        CarDecorator decorator2 = new SwimCarDecorator(flyCar);
        decorator2.show();
    }
}

测试结果：