设计模式理解

1. 设计模式，不是一种新的语言，也不是什么新api，更不是什么新的语法。
2. 设计模式，是前辈们，不断总结，不断打磨出的设计方法。不同设计模式适用于不同的场景。
3. 设计模式，公认的有23种设计模式，分别对应23种设计场景。这些设计模式，我们不用怀疑它的功能！因为这些设计模式是经过长期的实践考验，而留存下来的。
4. 千万不要以为有任何一种设计模式，能解决任何问题，每一种设计模式只能用于适用的场景，而不是万能的。
5. 设计模式有优点，也有缺点。我们不要为了适用设计模式而使用设计模式。切记防止“模式的滥用”！
6. 23种设计模式，背后其实是7大设计原则。也就是说，每个设计模式都归属于一个或多个设计原则。
7. 7大设计原则背后又是一个字——分，体会“分”字：活字印刷的例子
8. 7大设计原则分别是：

a.单一职责
b.里氏替换原则
c.依赖倒置原则
d.开闭原则
e.迪米特法则（最少知道原则）
f.接口隔离原则
g.组合优于继承原则

1. 学习设计模式，牢记两点

a. 开发代码的程序员，分为两种：作者（服务端程序员），用户（客户端程序员）
b.

七大设计原则

1.单一职责

单一职责解释：每个方法、每个类、每个框架只负责一件事情
比如：
Math.round() 只负责四舍五入功能，其他不管（方法）
Reader类，只负责只负责读取文本文件（类）
SpringMVC，只负责简化MVC的开发（框架）

• 案例：统计文本文件中有多少个单词。

  public class nagtive {
    public static void main(String[] args) {
        try{
            //读取文件的内容,统计一个文本文件中，有多少个字符。
            //Reader默认查询的码表是与操作系统一致的码表，
               //我们的操作系统是中文的，所以Reader就会使用GBK码表,而GBK码表一个汉字占2个字节
            //汉字字节以1开头，读到1时会与后一个字节结合读取，1开头一次读2个，0开头一次读1个
            Reader in = new FileReader("E:\\1.txt");
            BufferedReader bufferedReader = new BufferedReader(in);
            String line = null;
            StringBuilder sb = new StringBuilder("");
            while((line =bufferedReader.readLine()) != null){
                sb.append(line);
                sb.append(" ");
            }
            //对内容进行分割
            String[] words = sb.toString().split("[^a-zA-Z]+");
            System.out.println(words.length);
            bufferedReader.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
  }

  以上代码，违反了单一职责，缺点是:

1. 代码的重用性不高，如果有其他需求，必须，需要统计一个文件中的句子数量，则必须把文件加载到字符串中的代码，再写一遍。

2. 可读性低，别人一看这个方法，首先会被具体的算法搞晕，看代码的人根本看不出这个代码要干什么。

   public class postive {
    public static StringBuilder loadFile(String fileLocation) throws IOException {
            //读取文件的内容
            Reader in = new FileReader("E:\\1.txt");
            BufferedReader bufferedReader = new BufferedReader(in);
            String line = null;
            StringBuilder sb = new StringBuilder("");
            while ((line = bufferedReader.readLine()) != null) {
                sb.append(line);
                sb.append(" ");
            }
            bufferedReader.close();
            return sb;
    }
    public static String[] getWords(String regex, StringBuilder sb){
        //对内容进行分割
        return  sb.toString().split(regex);
    }
    public static void main(String[] args) throws IOException {
            //读取文件的内容
            StringBuilder sb = loadFile("E:\\1.txt");
            //对内容进行分割
            String[] words = getWords("[^a-zA-Z]+", sb);
            System.out.println(words.length);
    }
   }

   修改后的代码符合单一职责，优点如下：

3. 代码重用性提高

4. 可读性提高，代码就像大纲一样

遵守单一原则，可以给我们带来的好处是，提高了代码的可重用性，同时还让得到的数据不再有耦合，可以用来完成我们的个性化需求。

2.里氏替换原则

里氏替换原则解释：任何能够使用父类对象的地方，都应该能够透明的替换为子类对象。也就是说，子类对象可以随时随地替换父类对象，且替换完以后，语法不会报错，业务逻辑也不会出现问题！
方法重写：在子类和父类中，出现了返回类型相同、方法名相同、方法参数相同的方法时，构成方法重写方法重写的两个限制：

1. 子类重写父类的方法时，子类方法的访问修饰符不能比父类的更严格；
2. 子类重写父类的方法时，子类方法不能抛出比父类更多的异常。

为什么要有以上这2个限制。就是为了保证，在子类对象替换父类对象后，进行透明的替换，不需要更改代码，就是为了代码符合里氏替换原则。

继承的作用：

1. 提高代码重用性。
2. 多态的前提。

两个类能不能发生继承关系的依据是什么？

1. 有没有”is a”关系；
2. 在两个类有了”is a”关系之后，还要考虑子类对象在替换了父类对象之后，业务逻辑是否变化！如果变化，则不能发生继承关系。

案例：将长方形的宽改成比长大 1 。
反例：在父类Rectangular下，业务场景符合逻辑。现有子类Square，替换后如何。

public class negtive {
    static class Rectangular {
        private Integer width;
        private Integer length;
        public Integer getWidth() {
            return width;
        }
        public void setWidth(Integer width) {
            this.width = width;
        }
        public Integer getLength() {
            return length;
        }
        public void setLength(Integer length) {
            this.length = length;
        }
    }
    static class Square extends Rectangular {
        private Integer sideWidth;
        @Override
        public Integer getWidth() {
            return sideWidth;
        }
        @Override
        public void setWidth(Integer width) {
            this.sideWidth = width;
        }
        @Override
        public Integer getLength() {
            return sideWidth;
        }
        @Override
        public void setLength(Integer length) {
            this.sideWidth = length;
        }
    }
    static class Utils{
        public static void transform(Rectangular graph){
            while ( graph.getWidth() <= graph.getLength() ){
                graph.setWidth(graph.getWidth() + 1);
                System.out.println("长："+graph.getLength()+" : " +
                        "宽："+graph.getWidth());
            }
        }
    }
    public static void main(String[] args) {
    // Rectangular graph = new Rectangular();
        Rectangular graph = new Square();
        graph.setWidth(20);
       graph.setLength(30);
        Utils.transform(graph);
    }
}

替换后运行将是无限死循环，因为在正方形方法中，长宽修改的是一个变量，宽每次增一，长也会增一，所以宽永远追不上长，产生无限循环。
在向上转型的时候，方法的调用只和new的对象有关，才会造成不同的结果。在使用场景下，需要考虑替换后业务逻辑是否受影响。

3.依赖倒置原则

UML类图规则：

关联：一个类的对象，作为另一个类的字段
画法：实线加箭头
class Test{
}
class Test2{
private Test test；
//Test2关联Test
//Test被关联
}

依赖：一个类的方法中定义了另一个类作为局部字段
画法：虚线加箭头
class Test{
}
class Test2{
pubilic void test(){
Test test= new Test；
}
}

继承画法：实现加空心箭头
实现画法：虚线加空心箭头

依赖倒置原则解释：上层不能依赖于下层，它们都应该依赖于抽象。
什么是上层？什么是下层？调用别方法的，就是上层；被其他方法调用的，就是下层。
反例：人喂养动物

    static class Person{
        public void feed(Dog dog){
            dog.eat();
        }
    }
    static class Dog{
        public void eat() {
            System.out.println("狗啃骨头");
        }
    }
    public static void main(String[] args) {
        Person p = new Person();
        Dog d = new Dog();
        p.feed(d);
    }

 在上面的代码中，人要喂狗，依赖于有一条狗，人作为上层依赖于下层，这样有什么坏处呢？<br />坏处是，当变化来临时，比如，人又养了一只猫，那么上层人这个类当中，就必须在添加喂猫的方法；人又养了一只熊猫，那么上层人这个类当中，就必须在添加喂熊猫的方法。因此每当下层变动时，上层也会跟着变动，而我们希望下层变动时，上层不会跟着改变，即下层增加一个动物时，上层不知道，也不需要改。<br />**正例**：他们都应该依赖于抽象。

    interface Animal{
        void eat();
    }
    static class Person{
        public void feed(Animal animal){
            animal.eat();
        }
    }
    static class Dog implements Animal{
        public void eat() {
            System.out.println("狗啃骨头");
        }
    }
    public static void main(String[] args) {
        Person p = new Person();
        Dog d = new Dog();
        p.feed(d);
    }

 依赖倒转原则就是指：代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程。通过面向接口编程，抽象不应该依赖于细节，细节应该依赖于抽象。<br />![image.png](https://cdn.nlark.com/yuque/0/2021/png/21546143/1620289763286-709ab622-7142-49dc-bda1-de55369a9124.png#clientId=ue7d538fd-e73b-4&from=paste&height=197&id=u24b7cc58&margin=%5Bobject%20Object%5D&name=image.png&originHeight=662&originWidth=1143&originalType=binary&size=63868&status=done&style=none&taskId=ue1362a15-c851-4f5d-b6d5-d20f272136d&width=340)![image.png](https://cdn.nlark.com/yuque/0/2021/png/21546143/1620289741175-a01c272a-e2ef-4ab1-bc8a-76db769308b9.png#clientId=ue7d538fd-e73b-4&from=paste&height=206&id=KdWJh&margin=%5Bobject%20Object%5D&name=image.png&originHeight=707&originWidth=1232&originalType=binary&size=74357&status=done&style=none&taskId=u8f69e2bf-dff3-4936-a373-a21bc8d96b5&width=359)<br />箭头本是向下指，依赖于抽象后，箭头方向改变，依赖发生了改变，称为依赖倒置。上下层都依赖于抽象，指向抽象，上下层解耦。

4.开闭原则

开闭原则解释：a.对扩展新功能是开放的b.对修改原有功能是关闭的
比如：
有一个刮胡刀，刮胡刀的作用就是刮胡子，现在想让刮胡刀具备吹风机能力。
违反开闭原则的做法就是：把吹风功能加上了，可能不能刮胡子了。
符合开闭原则的做法就是：把吹风功能加上了，且没有影响以前的刮胡子功能。
案例：创建了一个汽车对象

class Car {
        private String band;
        private String color;
        private float price;
        public String getBand() {
            return band;
        }
        public void setBand(String band) {
            this.band = band;
        }
        public String getColor() {
            return color;
        }
        public void setColor(String color) {
            this.color = color;
        }
        public float getPrice() {
            return price;
        }
        public void setPrice(float price) {
            this.price = price;
        }
        @Override
        public String toString() {
            return "Car{" +
                    "band='" + band + '\'' +
                    ", color='" + color + '\'' +
                    ", price=" + price +
                    '}';
        }
    }
    public static void main(String[] args) {
        Car car = new Car();
        car.setBand("bm");
        car.setColor("red");
        car.setPrice(13.3f);
        System.out.println(car.toString());
    }

当变化来临时，例如汽车的价格现在需要打折（打8折），这时，我们在Car的源代码中修改，就违反了开闭原则。在开发时，我们应该，必须去考虑可能会变化的需求，属性在任何时候都可能发生改变，对于需求的变化，在要求遵守开闭原则的前提下，我们应该在开发中去进行扩展，而不是修改源代码。
反例：修改了源代码

 public void setPrice(float price) {
            this.price = (price*0.08f);
        }

开发时，我们应该要去考虑变化的需求，属性会在任何时刻都有可能产生变化。
对待变化时，我们应该选择扩展，而不是去修改源代码（ps：在强制要求符合开闭原则的情况下！）
正例：进行扩展

//进行扩展  
class DiscountCar extends Car{
        @Override
        public void setPrice(float price) {
            super.setPrice(price*0.08f);
        }
    }
    public static void main(String[] args) {
        //使用向上转型时，方法的调用只和new的对象有关
        Car car = new DiscountCar();
        car.setBand("bm");
        car.setColor("red");
        car.setPrice(130000f);
        System.out.println(car.toString());
    }

开闭原则应该遵循应用场景去考虑，如果源代码就是你自己写的，而且需求是稳定的，那么，直接修改源代码也是一个简单的做法，但当源代码是别人的代码或架构是，我们就要去符合开闭原则，防止破坏结构的完整性！

5.迪米特法则

迪米特法则解释：也叫最少知道原则。一个类对于其他类，要知道越少越好，体现封装的特性。只和朋友通信，不和陌生人通话。
反例：

public class negtive {
    class Computer{
        public  void  closeFile(){
            System.out.println("关闭文件");
        }
        public  void  closeScreen(){
            System.out.println("关闭屏幕");
        }
        public  void  powerOff(){
            System.out.println("断电");
        }
    }
    class Person{
        private Computer computer;
        public void offComputer(){
            computer.closeFile();
            computer.closeScreen();
            computer.powerOff();
        }
    }
}

这时候，Person知道了Computer的很多细节，对于用户来说不够友好，而且，用户还可能会调用错误，先断电，再保存文件，显然不符合逻辑，会导致文件出现未保存的错误。
其实对于用户来说，知道进行关机就行了。
正例：封装细节

public class postive {
    class Computer{
        public  void  closeFile(){
            System.out.println("关闭文件");
        }
        public  void  closeScreen(){
            System.out.println("关闭屏幕");
        }
        public  void  powerOff(){
            System.out.println("断电");
        }
        public void turnOff(){  //将细节实现进行封装
            this.closeFile();
            this.closeScreen();
            this.powerOff();
        }
    }
    class Person{
        private Computer computer;
        public void offComputer(){
            computer.turnOff();
        }
    }
}

前面说的，只和朋友通信，不和陌生人说话。先来明确一下什么才叫做朋友：

什么是朋友？

1. 类中的字段
2. 方法的返回值
3. 方法的参数
4. 方法中的实例对象
5. 对象本身
6. 集合中的泛型

总的来说，只要在自身内定义的就是朋友，通过其他方法得到的都只是朋友的朋友；但是，朋友的朋友不是我的朋友。
举个反例：

Copypublic class negtive {
     class Market{
        private  Computer computer;
        public Computer getComputer(){
            return this.computer;
        }
    }
    static class Computer{
        public  void  closeFile(){
            System.out.println("关闭文件");
        }
        public  void  closeScreen(){
            System.out.println("关闭屏幕");
        }
        public  void  powerOff(){
            System.out.println("断电");
        }
    }
    class Person{
        private Market market;
        Computer computer =market.getComputer(); 
        // //此时的 computer 并不是 Person 的朋友，只是 Market 的朋友。
    }
}

在实际开发中，要完全符合迪米特法则，也会有缺点：

• 在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的业务逻辑无关。
• 遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

因此，前人总结出，一些方法论以供我们参考：

1. 优先考虑将一个类设置成不变类。
2. 尽量降低一个类的访问权限。
3. 谨慎使用Serializable。
4. 尽量降低成员的访问权限。

虽然规矩很多，但是理论需要深刻理解，实战需要经验积累。路还很长。

6.接口隔离原则

接口隔离原则解释：设计接口时，接口的抽象应该是有意义的
反例：动物接口中定义的方法并不是被所有动物需要的

interface  Animal{
        void eat();
        void fly();
        void swim();
    }
    class Bird implements Animal{
        @Override
        public void eat() {
            System.out.println("吃东西");
        }
        @Override
        public void fly() {
            System.out.println("飞");
        }
        //鸟不会游泳，并不需要实现
        @Override
        public void swim() {
            System.out.println("游泳");
        }
    }

正例：接口抽象出有意义的层级，供需要的类去实现

interface  Flyable{
        void fly();
    }
interface  Swimable{
        void swim();
    }
interface  Eatable{
        void eat();
    }
class Bird implements Flyable,Eatable{
    .....
}
class Dog implements Swimable,Eatable{
    .....
}

客户端不应该依赖那些它不需要的接口。一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。使用多个接口比使用一个总接口要好。

7.组合优于继承原则

组合由于继承原则解释：复用别人的代码时，不宜使用继承，应该使用组合。
继承就是一个类继承另外一个类。我们已经知道，类和类之间有3种：a.继承 b.依赖 c.关联
“关联”可以细分为：

1. 组合
2. 聚合

所谓的组合，是关系强，聚合是关系弱。
需求：制作一个组合，该集合能够记录下曾经添加过多少元素。（不只是统计某一时刻）
反例 #1：

Copypublic class negtive_1 {
    static class MySet extends HashSet{
        private int count = 0;
        public int getCount() {
            return count;
        }
        @Override
        public boolean add(Object o) {
            count++;
            return super.add(o);
        }
    }
    public static void main(String[] args) {
        MySet mySet = new MySet();
        mySet.add("111111");
        mySet.add("22222222222222");
        mySet.add("2333");
        Set hashSet = new HashSet();
        hashSet.add("集合+11111");
        hashSet.add("集合+22222222");
        hashSet.add("集合+233333");
        mySet.addAll(hashSet);
        System.out.println(mySet.getCount());
    }
}

看似解决了需求，add方法可以成功将count进行自加，addAll方法通过方法内调用add，可以成功将count进行增加操作。
缺陷：JDK版本如果未来进行更新，addAll方法不再通过方法内调用add，那么当调用addAll进行集合添加元素时，count将不无从进行自加。需求也将无法满足。HashMap 就在1.6 1.7 1.8就分别更新了三次。
反例 #2：

Copypublic class negtive_2 {
    static class MySet extends HashSet{
        private int count = 0;
        public int getCount() {
            return count;
        }
        @Override
        public boolean add(Object o) {
            count++;
            return super.add(o);
        }
        @Override
        public boolean addAll(Collection c) {
            boolean modified = false;
            for (Object e : c)
                if (add(e))
                    modified = true;
            return modified;
        }
    }
    public static void main(String[] args) {
        MySet mySet = new MySet();
        mySet.add("111111");
        mySet.add("22222222222222");
        mySet.add("2333");
        Set hashSet = new HashSet();
        hashSet.add("集合+11111");
        hashSet.add("集合+22222222");
        hashSet.add("集合+233333");
        mySet.addAll(hashSet);
        System.out.println(mySet.getCount());
    }
}

亲自再重写addAll方法，确保addAll方法一定能调用到add方法，也就能对count进行增加操作。
但是，问题还是有的：

• 如果未来，HashSet新增了一个addSome方法进行元素的添加，那就白给了。
• 重写了addAll、add这两个方法，如果JDK中其他类的某些方法依赖于HashMap中的这两个方法，那么JDK中其他类依赖于HashMap中的这两个方法的某些方法就会有出错、崩溃等风险。

这时候，可以得出一些结论：
当我们不属于继承父类的开发团队时，是没办法保证父类代码不会被修改，或者修改时一定被通知到，这时候，就可能会出现需求满足有缺陷的情况。所以，但我们去复用父类的代码时，避免去重写或者新建方法，这样可以防止源代码结构发生改变带来的打击。也就是说，我们在重用代码时，应该是组合优于继承。
正例：

Copypublic class postive {
    static class MySet{
        private HashSet hashSet = new HashSet();
        private int count = 0;
        public int getCount() {
            return count;
        }
        public boolean add(Object o) {
            count++;
            return hashSet.add(o);
        }
        public boolean addAll(Collection c) {
            count += c.size();
            return hashSet.addAll(c);
        }
    }
    public static void main(String[] args) {
        MySet mySet = new MySet();
        mySet.add("111111");
        mySet.add("22222222222222");
        mySet.add("2333");
        Set hashSet = new HashSet();
        hashSet.add("集合+11111");
        hashSet.add("集合+22222222");
        hashSet.add("集合+233333");
        mySet.addAll(hashSet);
        System.out.println(mySet.getCount());
    }
}

利用组合，实现解耦，将HashSet和自定义类MySet由原来的继承关系改为了低耦合的组合关系。
JDK中的反例：Stack继承了Vector，因此违反了先进后出的原则。

设计模式

创建型

一、简单工厂

1. 每个模块负责自己的职责（单一职责），各个模块之间通过接口隔离
2. 每个模块都应该“承诺”自己对外暴露的接口是不变的。当模块内部发生变化时，其他模块是不需要知道的。这便是依赖于抽象而不依赖于实现（里氏替换原则）
3. 上层模块只需要知道下层模块暴露出的接口即可，至于实现细节不需要也不应该知道的（迪米特法则）
   工厂模式相关概念：
4. 产品: new 出的对象，都是产品。
5. 抽象产品: 抽象类、接口，都称之为抽象产品。
6. 产品簇: 多个抽象产品组成一个产品系列。
7. 产品等级: 产品簇中的每一个抽象产品都是产品等级。

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

//反例 
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类图如下：

这时候，产品来改需求来了，咱们现在这Noodles改名了，得改个特牛逼的名字Spaghetti，让用户记住咱们这是西餐意大利面。
因为原有设计是上面的反例，你得能从修改服务端的源代码开始，再修改客户端源代码。
这种设计过于脆弱，因为这样服务端源代码和客户端源代码是耦合的，改变会牵一发而动全身。
针对于以上缺点， 重构代码如下：

1. 添加了一个简单工厂： 根据参数的不同，而返回不同的具体产品。

2. 优点是：客户端再也不需要知道，具体产品的细节了（类名）

   //正例：
   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();
    }
   }

   缺点：

3. 从某种程度上违反单一职责。

4. 如果具体产品特别多，则简单工厂的代码将会十分臃肿。 （这也是有人把简单工厂叫做“上帝类”的原因。）
5. 增加了客户端代码的复杂度，客户端程序员，必须知道每个数字，都分别映射什么具体产品
6. 最关键的缺点：现在，客户端要添加新产品。客户端倒是能自己扩展一个新产品，但是为了把新产品加入简单工厂中，势必要违反“开闭原则”。

UML类图如下：

通过这样一个正例，把创建对象的代码全交给服务端处理，将服务端代码和客户端代码进行了解耦。这样做的好处，不只是服务端开发人员受益，当服务端代码修改时，客户端也不知道，也不需要知道。
简单工厂模式的缺点：

• 客户必须记住工厂中常量和具体产品的映射关系。
• 一旦产品品种体量增大到一定程度，工厂类将变得非常臃肿。
• 最致命的缺陷，增加产品时，就要修改工厂类。违反开闭原则。

由此，就引出了下一个设计模式： 工厂方法设计模式

二、工厂方法

// 正例
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类图如下：

工厂方法的优点：

1. 仍然具有简单工厂的优点：服务器端修改了具体产品的类名以后，客户端不知道！
2. 当客户端需要扩展一个新的产品时，不需要修改作者原来的代码，只是扩展一个新的工厂而已！

杠点：

1. 我们已经知道，简单工厂也好，工厂方法也好，都有一个优点，就是服务器端的具体产品类名变化了以后，客户端不知道！但是，反观我们现在的代码，客户端仍然依赖于具体的工厂的类名呀！此时，如果服务器端修改了具体工厂的类名，那么客户端也要随之一起修改！感觉折腾了一圈，又回到了原点！！！

• 对1的解释：工厂的名字，是为视为接口的。作者有责任，有义务，保证工厂的名字是稳定的。也就是说，虽然客户端依赖于工厂的具体类名，可是在IT业内，所有工厂的名字都是趋向于稳定（并不是100%不会变）。至少工厂类的名字，要比具体产品类的名字更加稳定！

1. 既然产品是我们自己客户端扩展出来的，那为什么不直接自己实例化呢？毕竟这个扩展出来的Lp这个产品，我们自己就是作者。我们想怎么改类名自己都能把控！为什么还要为自己制作的产品做工厂呢？

• 对2的解释：因为，作者在开发功能时，不仅仅只会开发一些抽象产品、具体产品、对应的工厂，还会配套地搭配一些提前做好的框架。

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

1. 如果源代码作者修改相关工厂类的类名，那这时候调用工厂类的客户端代码就需要修改了，这不如简单工厂呢？

首先这里要明确一个概念，工厂类在实际使用中，是相当于接口类的，接口类一般不允许进行修改（非必须），工厂类作者有责任，有义务保证工厂类的类名是稳定的，也就是说，工厂类是比产品类更加稳定的。

1. 既然使我们后面自己扩展的Rice类，为什么不直接实例化它，直接使用。我们就是作者，为什么不能直接使用？

这里需要扩展一下，有时候一个产品类并不是孤立的，它和其他类一起组成一个服务框架。
下面增加一些类：

/*===============服务端======================*/      
    //------------------------产品质检流程-----------------------、
    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);
    }

UML类图如下：

这时候，如果Rice没有他的工厂类，甚至都没办法参加质检，那还怎么卖？
所以编写工厂类并不只是单纯为了实例化某些产品类，而是能让配套服务通过工厂接口，得以调用工厂创建产品实例。
那为什么QualityInspection的checking方法不直接调用Food接口再进行产品的实例化呢？这时候回到简单工厂模式，产品类不同于工厂类，它是善变的，它会随着需求的变化而变化，这时候，直接依赖产品类的各种方法，将需要被修改，违反开闭原则。这是死路。
工厂方法模式的缺陷：

• 当业务需要的类型变多，目前只有食物，当产生饮料，日用品等类别时，我们又要创建新的工厂来实现，造成代码重复臃肿。

  三、抽象工厂

  针对工厂方法模式的缺陷，抽象工厂模式将进行改进，一个工厂负责创建一个产品簇的对象。
  工厂中的概念，产品（类），抽象产品（抽象类、接口），产品簇（多个有内在联系或逻辑关系的产品），产品等级（）。
  简述：在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
  抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

  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类图如下：
  
  可以看到，如果在需要进行一种N号螺丝或者螺母的扩展，只需要增加一个实现N号螺丝或者螺母接口的产品类，利用一个新增N号工厂进行创建即可。
  可以看到，抽象工厂仍然保持着简单工厂模式和工厂方法模式的优点：

• 服务端代码和客户端代码是低耦合的。（简单工厂模式）

• 所有这一切动作都是新增，不是修改，符合开闭原则。

还新增了一个特有的优点：

• 抽象工厂有效减少了工厂的数量，一个工厂就生产同一个产品簇的产品。

再次强调，一个抽象工厂负责创建同一个产品簇的对象。而产品簇是指多个存在内在联系的或者存在逻辑关系的产品。也就是6号工厂只生产6号的零部件，不负责生产8号零部件。不能不同产品簇的产品混合到一个工厂中进行生产。
缺陷：当增加产品簇时（增加6、8号螺帽的生产），这时候就要修改以前工厂（6、8号工厂）的源代码了。
解释：抽象工厂中，可以生产多个产品，这多个产品之间，必须有内在联系。同一个工厂中的产品都属于同一个产品簇！！不能把不同产品簇中的产品混合到一个抽象工厂的实现类中。
缺点：当产品等级发生变化时（增加产品等级），要修改以前所有的工厂代码的修改，违反了开闭原则
总结就是：

• 当产品簇比较固定时，考虑使用抽象工厂。

• 当产品簇经常变动时，不建议使用抽象工厂。

  四、原型

  原型模式解释：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
  用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

  public class negtive {
    /*==============服务端=======================*/
    static class Resume{
        private String name;
        private Integer age;
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
        public Integer getAge() {
            return age;
        }
        public void setAge(Integer age) {
            this.age = age;
        }
        @Override
        public String toString() {
            return "Resume{" +
                    "name='" + name + '\'' +
                    ", age=" + age +
                    '}';
        }
    }
    /*==============客户端=========================*/
    public static void main(String[] args) {
        Resume resume01= new Resume();
        resume01.setName("ling001");
        resume01.setAge(20);
        System.out.println(resume01);
        Resume resume02= new Resume();
        resume02.setName("ling002");
        resume02.setAge(23);
        System.out.println(resume02);
    }
  }

  复制多份简历需要一个个去new。Java就提供了这种复制粘贴的办法，不过他有自己的名字—Clone。

  public class postvie_01 {
        /*==============服务端=======================*/
        static class Resume implements Cloneable{
            private String name;
            private Integer age;
            public String getName() {
                return name;
            }
            public void setName(String name) {
                this.name = name;
            }
            public Integer getAge() {
                return age;
            }
            public void setAge(Integer age) {
                this.age = age;
            }
            @Override
            public String toString() {
                return "Resume{" +
                        "name='" + name + '\'' +
                        ", age=" + age +
                        '}';
            }
            @Override
            protected Object clone() throws CloneNotSupportedException {
                return super.clone();
            }
        }
        /*==============客户端=========================*/
        public static void main(String[] args) throws CloneNotSupportedException {
            Resume resume01= new Resume();
            resume01.setName("ling001");
            resume01.setAge(20);
            Resume resume02= (Resume) resume01.clone();
            resume02.setName("li666");
            System.out.println(resume01);
            System.out.println(resume02);
            System.out.println(resume01.equals(resume02));
        }
  }
  //克隆对象，得到一个新对象
  //思考1：clone方法，会不会引起构造器的调用？不会！那么clone方法是如何实现克隆对象的效果呢？
  //clone方法是直接赋值内存中的二进制。效率更高！
  //思考2：既然clone方法没有引起构造器的调用，那么克隆出的对象和原先的对象地址是否一致？不一致！
  //最终是两个不同空间中的对象。

  不需要new，只需要服务端先实现一个Cloneable，并重写clone方法即可。而且作用堪比new一个新的对象，因为克隆和被克隆的对象并不是同一个，equals的时候得到的是false的。
  这时候，新需求来了,为简历增加一个工作经历的内容。

  public class negtive_02 {
    /*==============服务端=======================*/
    static class Resume implements Cloneable{
        private String name;
        private Integer age;
        private Date workExperience;
        public Date getWorkExperience() {
            return workExperience;
        }
        public void setWorkExperience(Date workExperience) {
            this.workExperience = workExperience;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
        public Integer getAge() {
            return age;
        }
        public void setAge(Integer age) {
            this.age = age;
        }
        @Override
        public String toString() {
            return "Resume{" +
                    "name='" + name + '\'' +
                    ", age=" + age +
                    ", workExperience=" + workExperience +
                    '}';
        }
        @Override
        protected Object clone() throws CloneNotSupportedException {
            return super.clone();
        }
    }
    /*==============客户端=========================*/
    public static void main(String[] args) throws CloneNotSupportedException{
        Resume resume01= new Resume();
        Date date = new Date();
        resume01.setName("ling001");
        resume01.setAge(20);
        resume01.setWorkExperience(date);
        Resume resume02= (Resume) resume01.clone();
        resume02.getWorkExperience().setTime(0);
        System.out.println(resume02);
        System.out.println(resume01);
        System.out.println(resume01.equals(resume02));
    }
  }
  /*输出如下：
  Resume{name='ling001', age=20, workExperience=Thu Jan 01 08:00:00 CST 1970}
  Resume{name='ling001', age=20, workExperience=Thu Jan 01 08:00:00 CST 1970}
  false
  */

  这是一个关于深拷贝、浅拷贝的问题。

  深拷贝与浅拷贝

  浅拷贝（浅复制）：clone得到的对象a其实只是对被clone对象b的引用，即对象a是指向b对象上的。
  
  深拷贝（深复制）：clone得到的对象a是对被clone对象b的复制，即对象a和b是两个不同的对象，a只复制了b的内容。
  
  Java中，对一对象的clone中深拷贝对象的基本类型字段，浅拷贝引用类型字段。
  这时候要将浅拷贝改为深拷贝。
  只需要重写对象的clone方法即可。] ```java

    @Override
    public Object clone() throws CloneNotSupportedException {
        Resume clone = (Resume) super.clone();
        Date cloneDate = (Date) clone.getWorkExperience().clone();
        clone.setWorkExperience(cloneDate);
        return clone;
    }

/输出如下： Resume{name=’ling001’, age=20, workExperience=Thu Jan 01 08:00:00 CST 1970} Resume{name=’ling001’, age=20, workExperience=Fri May 21 20:43:31 CST 2021} false /

其实就是对**浅拷贝**的字段再进行**深拷贝**。<br />以上面用到的Date引用类型对象为例：<br />![image.png](https://cdn.nlark.com/yuque/0/2021/png/21546143/1621602071270-ed1305de-76a7-42cd-903b-0aa7d2bf3a24.png#clientId=u81a7129c-2981-4&from=paste&height=156&id=u7d8236b5&margin=%5Bobject%20Object%5D&name=image.png&originHeight=240&originWidth=795&originalType=binary&size=31503&status=done&style=none&taskId=u9171f666-cd23-4b09-941c-06203583e70&width=516.5)<br />可以看到Date是实现了Cloneable接口的，即表示Date也是可以进行clone（克隆）的。只需要将浅拷贝的Date再使用clone方法进行一次深拷贝，再赋值给clone的对象即可。具体参照上面重写的clone方法。<br />总结：<br />这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。
<a name="jzAUB"></a>
### 五、建造者
建造者模式解释：建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
```java
//明确实体类
public class Computer {
        private  String cpu;
        private String gpu;
        private  String Hd;
        private String RAM;
    public String getCpu() {
        return cpu;
    }
    public void setCpu(String cpu) {
        this.cpu = cpu;
    }
    public String getGpu() {
        return gpu;
    }
    public void setGpu(String gpu) {
        this.gpu = gpu;
    }
    public String getHd() {
        return Hd;
    }
    public void setHd(String hd) {
        Hd = hd;
    }
    public String getRAM() {
        return RAM;
    }
    public void setRAM(String RAM) {
        this.RAM = RAM;
    }
    @Override
    public String toString() {
        return "Computer{" +
                "cpu='" + cpu + '\'' +
                ", gpu='" + gpu + '\'' +
                ", Hd='" + Hd + '\'' +
                ", RAM='" + RAM + '\'' +
                '}';
    }
}

//反例1
public class negtive_01 {
    public static void main(String[] args) {
        Computer computer_01 = new Computer();
        computer_01.setCpu("R5-3600");
        computer_01.setGpu("RTX3060Ti");
        computer_01.setHd("SSD1TB");
        computer_01.setRAM("32GB");
        Computer computer_02 = new Computer();
        computer_02.setCpu("i5-10400");
        computer_02.setGpu("RTX3060");
        computer_02.setHd("SSD500GB");
        computer_02.setRAM("16GB");
        System.out.println(computer_02);
        System.out.println(computer_01);
    }
}

缺陷：建造复杂对象的时候，客户端程序猿要炸，造成客户端代码臃肿，且违反迪米特法则。

//反例2
public class negtive_02 {
    /*=============服务端==========================*/
    static class HighComputerBuilder {
        private Computer computer = new Computer();
        public Computer build() {
            computer.setCpu("R5-3600");
            computer.setGpu("RTX3060Ti");
            computer.setHd("SSD1TB");
            computer.setRAM("32GB");
            return computer;
        }
    }
    static class High_02ComputerBuilder {
        private Computer computer = new Computer();
        public Computer build() {
            computer.setCpu("i5-10400");
            computer.setGpu("RTX3060");
            computer.setHd("SSD500GB");
            computer.setRAM("16GB");
            return computer;
        }
    }
/*=====================客户端===============================*/
    public static void main(String[] args) {
        HighComputerBuilder builder_01 = new HighComputerBuilder();
        Computer computer_01 =builder_01.build();
        High_02ComputerBuilder builder_02 = new High_02ComputerBuilder();
        Computer computer_02 =builder_02.build();
        System.out.println(computer_01);
        System.out.println(computer_02);
    }
}

创造了建造者类，用于创建复杂对象。
UML类图如下：

缺陷：建造者遗漏部分建造步骤编译也会通过，会造成建造出来的对象不符合要求。比如，漏执行建造setHd时，使得值为null，这显然是不应该的，后续对象属性被调用时，可能会抛出空指针NullPointerException异常，会造成程序崩溃。

//反例3
public class negtive_03 {
    /*=============服务端==========================*/
    interface ComputerBuilder{
        Computer build();
        void setCpu();
        void setGpu();
        void setHd();
        void setRAM();
    }
    static class HighComputerBuilder implements ComputerBuilder{
        private Computer computer = new Computer();
        @Override
        public Computer build() {
            return computer;
        }
        @Override
        public void setCpu() {
            computer.setCpu("R5-3600");
        }
        @Override
        public void setGpu() {
            computer.setGpu("RTX3060");
        }
        @Override
        public void setHd() {
            computer.setHd("SSD1TB");
        }
        @Override
        public void setRAM() {
            computer.setRAM("32GB");
        }
    }
    static class High_02ComputerBuilder implements ComputerBuilder{
        private Computer computer = new Computer();
        @Override
        public Computer build() {
            return computer;
        }
        @Override
        public void setCpu() {
            computer.setCpu("i5-10400");
        }
        @Override
        public void setGpu() {
            computer.setGpu("RTX3060");
        }
        @Override
        public void setHd() {
            computer.setHd("SSD500GB");
        }
        @Override
        public void setRAM() {
            computer.setRAM("16GB");
        }
    }
    /*==============客户端=====================================*/
    public static void main(String[] args) {
        HighComputerBuilder builder_01 = new HighComputerBuilder();
        builder_01.setCpu();
        builder_01.setGpu();
        builder_01.setHd();
        builder_01.setRAM();
        Computer computer_01 =builder_01.build();
        High_02ComputerBuilder builder_02 = new High_02ComputerBuilder();
        builder_02.setCpu();
        builder_02.setGpu();
        builder_02.setHd();
        builder_02.setRAM();
        Computer computer_02 =builder_02.build();
        System.out.println(computer_01);
        System.out.println(computer_02);
    }
}

创造了建造者接口，创建者不会再遗漏步骤。
UML类图如下：

缺陷：

• 每一个builder都要自己去调用setXXX方法进行创建，造成代码重复。

• 需要客户端自己执行创建步骤，建造复杂对象的时候，容易造成客户端代码臃肿，且违反迪米特法则。而且客户端会出现遗漏步骤的情况。又回到了原点的感觉。

  //正例，建造者模式
  public class postive {
    /*=============服务端==========================*/
    interface ComputerBuilder{
        Computer getComputer();
        void setCpu();
        void setGpu();
        void setHd();
        void setRAM();
    }
    static class HighComputerBuilder implements ComputerBuilder {
        private Computer computer = new Computer();
        @Override
        public Computer getComputer() {
            return computer;
        }
        @Override
        public void setCpu() {
            computer.setCpu("R5-3600");
        }
        @Override
        public void setGpu() {
            computer.setGpu("RTX3060Ti");
        }
        @Override
        public void setHd() {
            computer.setHd("SSD1TB");
        }
        @Override
        public void setRAM() {
            computer.setRAM("32GB");
        }
    }
    static class High_02ComputerBuilder implements ComputerBuilder {
        private Computer computer = new Computer();
        @Override
        public Computer getComputer() {
            return computer;
        }
        @Override
        public void setCpu() {
            computer.setCpu("i5-10400");
        }
        @Override
        public void setGpu() {
            computer.setGpu("RTX3060");
        }
        @Override
        public void setHd() {
            computer.setHd("SSD500GB");
        }
        @Override
        public void setRAM() {
            computer.setRAM("16GB");
        }
    }
    //指挥者
    static class Director {
        public Computer build(ComputerBuilder builder){
            builder.setCpu();
            builder.setGpu();
            builder.setRAM();
            builder.setHd();
            return builder.getComputer();
        }
    }
    /*==============客户端=====================================*/
    public static void main(String[] args) {
        Director director = new Director();
        Computer computer_01 =director.build(new HighComputerBuilder());
        Computer computer_02 =director.build(new High_02ComputerBuilder());
        System.out.println(computer_01);
        System.out.println(computer_02);
    }
  }

  UML类图如下：
  
  此时在需要增加一个不同配置的A_Computer类型计算机，只需要编写一个A_Builder类实现ComputerBuilder接口，再传给指挥者Director进行创建即可得到一个A_Computer类型的Computer对象。符合开闭原则。
  总结一下建造者模式的优点：

• 创建对象的过程保持稳定。（通过ComputerBuilder接口保持稳定）

• 创建过程只需要编写一次（通过实现ComputerBuilder接口的类保持稳定）
• 保持扩展性，需要创建新类型的对象时，只需要创建新的Builder，再使用指挥者Director进行调用进行创建即可。

• 增加指挥者Director保证步骤稳定执行，客户端不需要知道创建对象的具体步骤，符合迪米特法则。

  建造者模式和工厂模式的区别

• 工厂模式注重new一个对象就可以，是否得到了这一对象，更多地关注new的结果。

• 建造者模式注重保证new的对象稳定可用，保证不出现细节缺漏，更多关注new的细节、过程。

  结构型

  一、装饰器

  解释：在不改变现有对象结构的情况下，为现有对象添加新功能。 ```java / 星巴克是卖咖啡的， 一开始饮料种类比较少，所以使用继承，看不出什么问题。 每种咖啡，都有描述，都有价格。 这是所有咖啡的共性，既然是共性，就要上提到父类Beverage中。 /

abstract class Beverage {