有兴趣的同学欢迎加入QQ学习交流群：1126298731

有问题欢迎提问，大家一起在学习Java的路上打怪升级！(o゜▽゜)o☆[BINGO!]

九，设计模式（Design Pattern,DP）

1，简介

1.1 设计模式的产生背景

“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

直到 1990 年，软件工程界才开始研讨设计模式的话题。

1995年，“四人组”（Gang of Four，GoF）合作出版了《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书，在书籍中收录了 23 个设计模式，这是设计模式领域里程碑的事件，导致了软件设计模式的突破。

直到今天，狭义的设计模式还是该书中所介绍的23种经典设计模式。

1.2 设计模式的概念

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性

2，原则一——开闭原则（Open Closed Principle，OCP）

2.1 概念

开闭原则由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。简单点说就是是：一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那么什么是软件实体呢？

这里的软件实体包括以下几个部分：

项目中划分出的模块

类与接口

方法

一个软件产品在她的生命周期内一般都会发生变化，开闭原则视为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

2.2 案例

1）代码

IBook.java（接口）

package com.xrh.principle.ocp;

public interface IBook {
    String getName();
    int getPrice();
    String getAuthor();
}

NovelBook.java

package com.xrh.principle.ocp;

public class NovelBook implements IBook{
    private String name;
    private int price;
    private String author;

    public NovelBook(String name, int price, String author) {
        this.name = name;
        this.price = price;
        this.author = author;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public int getPrice() {
        return this.price;
    }

    @Override
    public String getAuthor() {
        return this.author;
    }
}

BookStore.java

package com.xrh.principle.ocp;

import java.util.ArrayList;

public class BookStore {
    private static ArrayList<IBook> bookList=new ArrayList<>();

    static {
        bookList.add(new NovelBook("红楼梦", 9900, "曹雪芹"));
        bookList.add(new NovelBook("侠客行", 8900, "金庸"));
        bookList.add(new NovelBook("原则", 6900, "瑞达利欧"));
        bookList.add(new NovelBook("海贼王1", 4900, "尾田荣一郎"));
    }

    public static void main(String[] args) {
        System.out.println("卖书的记录如下----------------------");
        for (IBook book : bookList) {
            System.out.println("书籍名称："+book.getName()+"\t\t作者："+book.getAuthor()+"\t\t价格：￥"+book.getPrice()/100.0+"元");
        }
    }
}

2）考虑场景：图书打折促销，70元以上图书九折销售，70元以下八折销售

方案一：在接口中添加新的方法int getOffPrice（）

在IBook接口里新增getOffPrice()方法，专门用于进行打折，所有的实现类都实现该方法。但这样修改的后果就是，实现类NovelBook要修改，书店类BookStore中的main方法也要修改，同时，IBook作为接口应该是稳定且可靠的，不应该经常发生变化，因此，该方案被否定。

方案二：在实现类NovelBook中修改getPrice方法，添加价格逻辑判断，并赋值

修改NovelBook类中的方法，直接在getPrice()方法中实现打折处理，这个方法可以是可以，但如果采购书籍的人员要看价格怎么办，由于该方法已经进行了打折处理，因此采购人员看到的也是打折后的价格，会因信息不对称出现决策失误的情况。因此，该方案也不是一个最优的方案。

方案三：添加子类，重写价格的方法（开闭原则）

方案一、二，都是在对原有代码进行修改，而不是扩展；

增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是BookStore中static静态块中）通过 OffNovelBook类产生新的对象，完成业务变化对系统的最小开发。这样修改也少，风险也小。

OffNovelBook.java

package com.xrh.principle.ocp;

public class OffNovelBook extends NovelBook{
    public OffNovelBook(String name, int price, String author) {
        super(name, price, author);
    }

    @Override
    public int getPrice() {
        int sellPrice=super.getPrice();
        int offPrice=0;
        if(sellPrice>7000){
            offPrice=sellPrice*90/100;
        }else{
            offPrice=sellPrice*80/100;
        }
        return offPrice;
    }
}

BookStore.java

2.3 总结

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。

1. 对软件测试的影响

软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。

2. 可以提高代码的可复用性

粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。

3. 可以提高软件的可维护性

遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护

3，原则二——单一职责原则（Single responsibility principle，SRP）

3.1 定义

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；

2. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

举例

以上是符合单一职责原则的吗？说白了是一个接口只负责一件事情吗？是只有一个原因引起变化么？

好像不是哦！

其实他负责了两个内容：1、协议管理，2、数据传送。

dial()和hangup()两个方法实现的是协议管理；chat()方法负责的是数据的传送。

那么协议的改变可能引起接口或者实现类的变化；同样数据传送（电话不仅可以打电话，还能上网）的变化也可能会引起接口或实现类的变化。

两个原因都能引起变化，而两个职责直接是互不影响的，所以可以考虑拆分为两个接口。

3.2 单一职责原则的优点

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

提高类的可读性。复杂性降低，自然其可读性会提高。

提高系统的可维护性。可读性提高，那自然更容易维护了。

变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

PS：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

但是原则是死的，人是活的。所以有些时候我们可以为了效率，牺牲一定的原则性

4，原则三——里氏替换原则（Liskov Substitution Principle，LSP）

这是一个爱恨纠葛的父子关系的故事。该原则可以理解为：子类可以替换父类。

父子类实在我们学习继承这个知识点的时候学习到的概念。我们先来回忆一下继承的优缺点：

优点：

1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；

2. 提高代码的重用性；

3. 提高代码的可扩展性，子类可形似于父类，但异于父类，保留了自己独特的个性；其实很多开源框架的扩展都是通过继承父类实现的；

4.提供产品或者项目的开放性。

缺点：

1. 继承是侵入性的，只要继承就必须拥有父类的所有方法和属性；

2. 降低了代码的灵活性。子类必须拥有父类的属性和方法，让子类中多了约束

3. 增加了耦合，当父类的常量、变量或者方法被修改了，需要考虑子类的修改，所以一旦父类有了变动，很可能会造成非常糟糕的结果，要重构大量的代码。

java中使用extends关键字来实现继承，采用的是单一继承的规则，C++则采用了多重继承的规则，即一个子类可以继承多个父类。从整体上上看，利大于弊，怎么才能更大的发挥“利”的作用呢？

解决方案就是引入里氏替换原则。什么是里氏替换原则呢？

4.1 定义

该原则有两个定义:

第一种：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果每一个类型S的对象o1，都有一个类型T的对象o2，在以T定义的所有程序P中将所有的对象o2都替换为o1，而程序P的行为没有发生变化，那么S是T的子类。）。

第二种：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（所有引用基/父类的地方必须能透明地使用其子类对象。）

第一个定义看起来有点难，其实意思就是说:在一个程序中，如果可以将一个类T的对象全部替换为另一个类S的对象，而程序的行为没有发生变化，那么S是T的子类。

第二个定义明显要比第一个定义更容易理解，非常的清晰明确。通俗地讲，就是任何一个使用父类的地方，你都可以把它替换成它的子类，而不会发生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必可以替换。

4.2 含义

里氏替换原则是继承复用的基石，它为良好的继承定义了一个规范，定义中包含了4层含义：

1）子类必须完全实现父类的方法

我们以前做过的项目中，经常定义一个接口或者抽象类，然后编码实现，调用类则直接传入接口或者抽象类，其实这就是已经在使用历史替换原则了

举例

AbstacTGun.java（抽象接口）

package com.wln.principle.lvp;

//枪的抽象类
public abstract class AbstacTGun {
    //射击
    public abstract void shoot();
}

Handgan.java（手枪，继承接口）

package com.wln.principle.lvp;
//手枪：携带方便但是射程短
public class Handgan extends AbstacTGun{
    @Override
    public void shoot() {
        System.out.println("手枪射击------------");
    }
}

Rifle.java（步枪，继承接口）

package com.wln.principle.lvp;
//步枪：威力大射程远
public class Rifle extends AbstacTGun{
    @Override
    public void shoot() {
        System.out.println("步枪射击------------");
    }
}

MachineGun.java（机枪，继承接口）

package com.wln.principle.lvp;
//机枪：威力更大连续发射
public class MachineGun extends AbstacTGun{
    @Override
    public void shoot() {
        System.out.println("机枪射击------------");
    }
}

Solider.java

package com.wln.principle.lvp;
//士兵：使用枪支
public class Solider {
    //士兵使用的枪
    private AbstacTGun gun;
    //通过set方法给士兵配枪（参数为父类或抽象接口，体现里氏替换原则）
    public void setGun(AbstacTGun gun) {
        this.gun = gun;
    }
    public void killEnemy(){
        System.out.println("士兵杀敌：");
        gun.shoot();
    }
}

Client.java（应用场景）

package com.wln.principle.lvp;

public class Client {
    public static void main(String[] args) {
        //定义一个士兵
        Solider xunSanDuo=new Solider();
        //给许三多配枪
        xunSanDuo.setGun(new Rifle());
        xunSanDuo.killEnemy();
    }
}

在场景类中，给士兵配枪的时候可以是三种枪中的任何一个，其实士兵类可以不用知道是哪种的枪（子类）被传入。

PS：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或者接口，说明类的设计违背了里氏替换原则

2）子类中可以增加自己特有的方法

类都有自己的属性和方法，子类当然也不例外。除了从父类继承过来的，可以有自己独有的内容。为什么要单独列出来，是因为里氏替换原则是不可以反过来用的。也就是子类出现的地方，父类未必可以胜任。

我们继续上面的案例：步枪下面还有几个比较知名的种类：例如AK47和AUG狙击步枪。

AUG.java（狙击步枪，继承自步枪）

package com.wln.principle.lvp;
//AUG狙击步枪
public class AUG extends Rifle{
    //狙击枪都携带了精准的望远镜
    public void zoomOut(){
        System.out.println("通过望远镜观察敌人：");
    }

    @Override
    public void shoot() {
        System.out.println("AUG射击-----------");
    }
}

Snipper.java（狙击手，继承自士兵）

package com.wln.principle.lvp;
//狙击手
public class Snipper extends Solider{

    public void killEnemy(AUG aug) {// 重载
        //先观察
        aug.zoomOut();
        aug.shoot();
    }
}

场景类中我们可以直接使用子类，狙击手是依赖枪支的，别说换一个型号的枪，就是同一个型号的枪都会影响射击，所以这里直接传递子类。

如果我们直接使用父类传递进来可以吗？

Client.java（更新应用场景）

package com.wln.principle.lvp;

public class Client {

    public static void main(String[] args) {
        //定义一个狙击手
        Snipper hanGuang=new Snipper();
        //配枪
        hanGuang.setGun(new AUG());
        // 将子类强转为父类则会出错
        //hanGuang.setGun((AUG)new Rifle());
        hanGuang.killEnemy();
    }
    public static void main1(String[] args) {
        //定义一个士兵
        Solider xunSanDuo=new Solider();
        //给许三多配枪
        xunSanDuo.setGun(new Rifle());
        xunSanDuo.killEnemy();
    }
}

运行注释的代码，会抛出异常，这就是我们经常说的向下转型是不安全的。从里氏替换原则来看：子类出现的地方，父类未必可以出现

3）当子类覆盖或实现父类的方法时，方法的输入参数（方法的形参）要比父类方法的输入参数更宽松

LSP.java

package com.wln.principle.lvp;

import java.util.HashMap;
import java.util.Map;

public class LSP {
    //当子类覆盖或者实现父类的方法时，方法的输入参数要比父类的方法输入的参数更宽松
    class Parent{
        public void fun(HashMap map){
            System.out.println("父类被执行....");
        }
    }
    class Sub extends Parent{
        public void fun(Map map){
            System.out.println("子类被执行....");
        }
    }

    public static void main(String[] args) {
        System.out.println("父类运行的结果：");
        LSP lsp=new LSP();
        Parent a=lsp.new Parent();
        HashMap<Object,Object> hashMap=new HashMap<>();
        a.fun(hashMap);
        //父类存在的地方可以用子类替换
        //子类替换父类
        System.out.println("子类替换父类运行的结果：");
        Sub b=lsp.new Sub();
        b.fun(hashMap);
    }
}

ps:这里子类并非重写了父类的方法，而是重载了父类的方法。因为子类和父类的方法的输入参数是不同的。

子类方法的参数Map比父类方法的参数HashMap的范围要大，所以当参数输入为HashMap类型时，只会执行父类的方法，不会执行父类的重载方法。这符合里氏替换原则。

4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

LSP1.java

package com.wln.principle.lvp;

import java.util.HashMap;
import java.util.Map;

public class LSP1 {
    //当子类实现父类的抽象方法时，方法的后置条件要比父类更严格
    abstract class Parent{
        public abstract Map fun();
    }
    class Sub extends Parent{
        @Override
        public HashMap fun(){
            HashMap map=new HashMap();
			map.put("b", "子类被执行");
			return map;
        }
    }

    public static void main(String[] args) {
        LSP1 lsp1=new LSP1();
        Parent a=lsp1.new Sub();
        System.out.println( a.fun());

    }
}

如果子类重写父类方法的返回值，类型更宽松（比如子类返回Map，而父类返回HashMap），编译时就会直接报错（飘红）

4.3 作用

1. 里氏替换原则是实现开闭原则的重要方式之一。

2. 它克服了继承中重写父类造成的可复用性变差的缺点。

3. 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法（可以重载）。

如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系

5，原则四——依赖倒置原则（Dependence Inversion Principle，DIP）

5.1 定义

依赖倒置原则的原始定义为:High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions。

其实里面包含了三层含义：

高层模块不应该依赖低层模块，两者都应该依赖其抽象；

抽象不应该依赖细节，

细节应该依赖抽象。

核心思想：要面向接口编程，不要面向实现编程。

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。

由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。

使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成

5.2 作用

依赖倒置原则可以降低类间的耦合性。

依赖倒置原则可以提高系统的稳定性。

依赖倒置原则可以减少并行开发引起的风险。

依赖倒置原则可以提高代码的可读性和可维护性

5.3 举例

Benz.java

package com.wln.principle.dip;
//奔驰车
public class Benz {
    public void  run(){
        System.out.println("奔驰车飞驰-----------------");
    }
}

Driver.java

package com.wln.principle.dip;
//司机类实现司机接口
public class Driver {
    public void drive(Benz benz){
        System.out.println("司机开车：");
        car.run();
    }
}

BMW.java

package com.wln.principle.dip;

import javax.sound.midi.Soundbank;
//宝马车
public class BMW{
    public void run(){
        System.out.println("宝马车飞驰------------");
    }
}

Client.java（应用场景）

package com.wln.principle.dip;
//场景类
public class Client {

    public static void main(String[] args) {
        Driver james=new Driver();
        Car benz=new Benz();
        Car bmw=new BMW();
        james.drive(bmw);
    }
}

运行Client发现报错，司机只能开奔驰车，不能开宝马（原因，司机和车的类型是紧耦合的关系）

很显然，我们的设计不合理：司机类和奔驰车类之间是紧耦合的关系，结果就是系统的可维护性降低、可阅读性降低，两个相似的类要阅读两个类；这里增加了一个车类就需要修改司机类，让程序变得不稳定。这样我们就证明了不使用依赖导致原则就没有前两个好处。

继续证明“减少并行开发的风险”，什么是并行开发风险？本来只是一段程序的错误或者异常，逐步波及一个功能、一个模块，甚至最后毁掉整个项目。

为什么并行开发有这也的风险？假如一个团队有20个人，各人负责不同的功能模块，A负责汽车类，B负责司机类......在A未完成的情况下，B不能完全的编写代码，因为缺少汽车类编译器编译根本通不过，就更不用说单元测试了！

在这种不使用依赖倒置原则的情况下，所有的开发都是“单线程”的，只能是A 做完B再做......在早期的小型项目中还可以，但在现在的中大型项目中就不合适了，需要团队人员同时并行开发，所以这个时候依赖原则的作用就体现出来了。

因为根据上面的案例已经说明不使用依赖倒置原则就会增加类直接的耦合性，降低系统的稳定性、可读性和维护性，增加了并行开发的风险。

依据依赖倒置原则更新代码

package com.wln.principle.dip;
//汽车接口
public interface ICar {

    void run();
}

//奔驰车
public class Benz implements ICar{
    @Override
    public void  run(){
        System.out.println("奔驰车飞驰-----------------");
    }
}

//宝马车
public class BMW implements ICar{
    @Override
    public void run(){
        System.out.println("宝马车飞驰------------");
    }
}

//司机接口
public interface IDriver {
    //司机驾驶汽车：通过传入ICar接口实现抽象之间的依赖关系
    void drive(ICar car);
}

//司机类实现司机接口
public class Driver implements IDriver{
    @Override
    public void drive(ICar  car){
        System.out.println("司机开车：");
        car.run();
    }
}

//场景类：属于高层模块，高层业务逻辑，他对低层的依赖都建立在抽象上
public class Client {

    public static void main(String[] args) {
        IDriver james=new Driver();
        ICar benz=new Benz();
        ICar bmw=new BMW();

        james.drive(bmw);
    }
    public static void main1(String[] args) {
        Driver james=new Driver();
        Benz benz=new Benz();
        BMW bmw=new BMW();
        //james.drive(bmw);
    }
}

james和benz表明的类型都是接口，是抽象的，虽然在实例化对象的时候调用了低层模块，但是后续所有操作中， james都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。

如果我们此时再新增一个低层模块，只修改业务场景类，也就是高层模块，对其它低层模块不需要做任何修改，业务依然可以运行，把变更引起的风险扩散降到最低。

依赖倒置对并行开发的影响。只要定义好了接口，即使负责Car开发的程序员工作滞后，我们依然可用进行测试。引入了JMock工具，根据抽象虚拟一个对象进行测试（不了解该测试工具也没关系，以后有机会再了解）。

测试类编写

package com.wln.principle.dip;

import junit.framework.TestCase;
import junit.framework.TestResult;
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.junit.Test;

public class Test1 extends TestCase {

    Mockery context=new JUnit4Mockery();

    @Test
    public void test1(){
        ICar car=context.mock(ICar.class);
        IDriver driver=new Driver();
        context.checking(new Expectations(){
   
   {
            oneOf(car).run();
        }
        });
        driver.drive(car);
    }
}

5.4 依赖倒置原则的实现方法

依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

1. 每个类尽量提供接口或抽象类，或者两者都具备。

2. 变量的声明类型尽量是接口或者是抽象类。

3. 任何类都不应该从具体类派生。

4. 尽量不要覆写基类的方法

5. 使用继承时结合里氏替换原则

6，原则五——接口隔离原则（Interface Segregation Principle，ISP）

6.1 定义

接口隔离原则要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。

以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。

单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建

6.2 举例

IPrettyGirl.java

package com.wln.principle.isp;

//美女接口
public interface IPrettyGirl {

}

PrettryGirl.java

package com.wln.principle.isp;

import java.awt.image.ImageConsumer;

public class PrettryGirl implements IPrettyGirl {
    private String name;

    public PrettryGirl(String name) {
        this.name = name;
    }

    @Override
    public void goodLooking() {
        System.out.println(this.name+"面容：倾国倾城比天仙");
    }

    @Override
    public void niceFigure() {
        System.out.println(this.name+"身材:窈窕淑女赛西施");
    }

    @Override
    public void greatTemperament() {
        System.out.println(this.name+"气质：亭亭玉立似贵妃");
    }
}

AbstractSearcher.java

package com.wln.principle.isp;

public abstract class AbstractSearcher {

    protected  IPrettyGirl girl;

    public AbstractSearcher(IPrettyGirl girl) {
        this.girl = girl;
    }

    public abstract void search();
}

Searcher.java

package com.wln.principle.isp;

public class Searcher extends AbstractSearcher{
    public Searcher(IPrettyGirl girl) {
        super(girl);
    }

    @Override
    public void search() {
        System.out.println("搜索到的美女展示如下：");
        super.girl.goodLooking();
        super.girl.niceFigure();
        super.girl.greatTemperament();
    }
}

Client.java（使用场景）

package com.wln.principle.isp;

public class Client {
    public static void main(String[] args) {
        //定义一个美女
        IPrettyGirl reba=new PrettryGirl("迪丽热巴");
        AbstractSearcher searcher=new Searcher(reba);
        searcher.search();
    }
}

我们的审美观点一直在改变，美女的定义也在变化。例如看到一个女孩：身材面容一般，但是气质特别好，我们也会把她成为美女，于是产生了气质美女，但是我们的接口中却定义了美女都必须具备三个条件，按照这个标准，气质美女就不是美女了，怎么办呢？

重新扩展一个美女类，只实现气质方法，其他两个方法置空就好啦！可是星探类AbstractSearcher依赖的是 IPettyGirl接口，它有3个方法，星探的方法是不是要修改？

分析到这里，我们发现其实是IPettyGirl的设计有缺陷，过于庞大，容纳了一些可变的因素，根据接口隔离的原则，星探AbstractSearcher应该依赖具有部分特质的女孩子，而我们却把这些都放到了一个接口中。

找到问题原因，接下来就解决问题：我们把臃肿的接口分为两个：一个面容身材好接口，一个气质好接口。

更新代码如下：

//美女接口
public interface IGoodsBodyGirl {
    //天使面孔
    void goodLooking();
    //魔鬼身材
    void niceFigure();
}

//美女接口
public interface IGreatTempermentGirl {
    //有气质
    void greatTemperament();
}


//美女实现类:可以根据需求自行选择实现一个或者多个接口
public class PrettryGirl implements IGoodsBodyGirl,IGreatTempermentGirl {
    private String name;

    public PrettryGirl(String name) {
        this.name = name;
    }

    @Override
    public void goodLooking() {
        System.out.println(this.name+"面容：倾国倾城比天仙");
    }

    @Override
    public void niceFigure() {
        System.out.println(this.name+"身材:窈窕淑女赛西施");
    }

    @Override
    public void greatTemperament() {
        System.out.println(this.name+"气质：亭亭玉立似贵妃");
    }
}

6.3 优点

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。

3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。

5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

6.4 接口隔离原则的实现方法

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。

为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。

提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

7，原则六——迪米特原则（Law of Demeter，LoD）

7.1 定义

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，它要求一个对象应该对其他对象有最少的了解。通俗的说，一个类应该对自己需要耦合或调用的类知道的最少，被耦合或调用的类的内部是如何复杂都与我无关，我就知道你提供的public方法就好。

迪米特法则还是在讲如何减少耦合的问题，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。

迪米特法则还有一个定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

什么叫做直接的朋友呢？每个对象都必然会和其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系有很多比如组合、聚合、依赖等等。包括以下几类：

1. 当前对象本身（this）

2. 当前对象的方法参数（以参数形式传入到当前对象方法中的对象）

3. 当前对象的成员对象

4. 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友

5. 当前对象所创建的对象

7.2 迪米特法则的优点

降低了类之间的耦合度，提高了模块的相对独立性。

由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

7.3 迪米特法则的实现方法

从迪米特法则的定义和特点可知，它强调以下两点：

1. 从依赖者的角度来说，只依赖应该依赖的对象。

2. 从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

1. 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

2. 在类的结构设计上，尽量降低类成员的访问权限。

3. 在类的设计上，优先考虑将一个类设置成不变类。

4. 在对其他类的引用上，将引用其他对象的次数降到最低。

5. 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

6. 谨慎使用序列化（Serializable）功能。

7.4 举例

举个栗子：明星平时档期都很满，例如拍电影、演出、粉丝见面会等等，那么他们的这些日程是怎么来的呢？一般都是由经纪人负责处理。这里的经纪人是明星的朋友，而见面会上的粉丝和拍电影或举办演出的媒体公司是陌生人，所以适合使用迪米特法则

package com.wln.principle.dop;

public class Client {
    public static void main(String[] args) {
        Agent agent=new Agent();
        agent.setStar(new Star("迪丽热巴"));
        agent.setFans(new Fans("小九"));
        agent.meeting();
        agent.setCompany(new Company("荔枝电视台"));
        agent.business();
    }
}

// 经纪人
class Agent{
    private Star star;
    private Fans fans;
    private Company company;

    public void meeting(){
        System.out.println(this.fans.getName()+"与明星"+this.star.getName()+"见面啦");
    }

    public void business(){
        System.out.println(this.company.getName()+"与明星"+this.star.getName()+"商谈合作");
    }

    public void setStar(Star star) {
        this.star = star;
    }

    public void setFans(Fans fans) {
        this.fans = fans;
    }

    public void setCompany(Company company) {
        this.company = company;
    }
}

// 明星
class Star{
    private  String name;

    public Star(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

// 粉丝
class Fans{
    private  String name;

    public Fans(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

// 公司
class Company{
    private  String name;

    public Company(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

8，设计模式之创建型模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。

创建型模式分为以下几种。

8.1 创建型模式——单例模式

案例：我是皇帝，独此一家。

中国自从秦始皇确立了皇帝这个职位之后，同一个时期基本上上就只有一个人孤零零的坐在皇位上啦。这种情况的好处就是大家好办事，大家讨论或者汇报大事的时候只要提及皇帝，每个人都知道指的是谁，不需要在皇帝面前加上特定的称呼。

这种过程反应到软件设计领域就是：一个类只能产生一个对象（皇帝），大家对他的依赖都是相同的。我们把皇帝这种特殊的职位通过程序来实现。

8.1.1 举例

Emperor.java

package com.wln.dp.singleton;

import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.Random;

//皇帝类
public class Emperor {
    private static Emperor emperor = null;
    
    //构造方法私有，避免在类的外部创建对象
    private Emperor() {
    }

    private Emperor(String name) {
        this.name = name;
    }

    //提供一个产生实例的方法
    public static Emperor getInstance(){
        if(emperor == null) {
            emperor = new Emperor();
        }
        return emperor;
    }
    public void work(){
        System.out.println("我是皇帝, 有事起奏，无事退朝！");
    }
}

Minister.java

package com.wln.dp.singleton;
//大臣
public class Minister {
    public static void main(String[] args) {
        for(int i=1;i<=5;i++){
            Emperor emperor=Emperor.getInstance();// 每次执行都获得的是同一个对象
            System.out.print("第"+i+"天：");
            emperor.work();
        }
    }
}

大臣每天上朝汇报国事的对象都是同一个皇帝，这就是单例模式！

8.1.2 单例模式的定义以及特点

1）定义

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

Ensure a class has only one instance,and provide a global point of access to it

2）特点

单例类只有一个实例对象；

该单例对象必须由单例类自行创建；

单例类对外提供一个访问该单例的全局访问点。

8.1.3 单例模式的分类

上面的单例模式，在低并发的情况下可能不会出现问题，如果并发量增大，内存中就会出现多个实例，就不是真正意义上的单例。为什么会出现这种情况呢？

解决线程不安全的方式有多种。我们先将上面代码的单例模式修改为线程安全的：

懒汉式单例：

该模式的特点是类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。

关键字 volatile 和 synchronized，能保证线程安全，但是每次访问时都要同步，会影响性能，且消耗更多的资源，这是懒汉式单例的缺点。

饿汉式单例：

该模式的特点是类一旦加载就创建一个单例，保证在调用 getInstance 方法之前单例已经存在了。而且该方式是线程安全的。

8.1.4 单例模式的使用场景

某类只要求生成一个对象的时候，如一个航班的机长、每个人的身份证号等。

当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

当某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。

在计算机系统中， Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用程序的日志对象、数据库的连接池、网站的计数器、Web 应用的配置对象、应用程序中的对话框、系统中的缓存等常常被设计成单例。

8.1.5 单例模式的优缺点

优点：

在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例。

避免对资源的多重占用（比如写文件操作）。

单例模式可以在系统设置全局的访问点，优化和共享资源访问。

缺点：

单例模式一般没有接口，扩展很困难。如果要扩展，只能修改代码。

与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

8.1.6 单例模式的扩展

单例模式可扩展为有限的多例（Multitcm）模式，这种模式可生成有限个实例并保存在 ArmyList 中，客户需要时可随机获取。

更新代码

package com.wln.dp.singleton;

import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.Random;

//皇帝类
public class Emperor {
    private String name;
    private static final  int maxNum=2;
    private static ArrayList<Emperor> list=new ArrayList<>(2);
    static {
            list.add(new Emperor("皇帝：朱祁镇"));
            list.add(new Emperor("皇帝：朱祁钰"));
    }
    //构造方法私有，避免在类的外部创建对象
    private Emperor() {
    }

    private Emperor(String name) {
        this.name = name;
    }

    //提供一个产生实例的方法
    public static Emperor getInstance(){
        int index=new Random().nextInt(maxNum);
        return list.get(index);
    }
    public void work(){
        System.out.println("我是皇帝"+name+"：有事起奏，无事退朝！");
    }
}
----------------------------
package com.wln.dp.singleton;
//大臣
public class Minister {
    public static void main(String[] args) {
        for(int i=1;i<=5;i++){
            Emperor emperor=Emperor.getInstance();
            System.out.print("第"+i+"天：");
            emperor.work();
        }
    }
}

03-Java核心类库_设计模式【未完待续】