1.19Java设计模式

1.19.1设计模式七大原则

1.19.1 设计模式目的与原则

1.19.1.1 设计模式目的

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，具有更好

1. 代码重用性
2. 可读性（即，编程规范性）
3. 可扩展性（即，方便增加新功能）
4. 可靠性（即，新增功能后，对原有功能没有影响）
5. 使程序呈现高内聚，低耦合的特性（高内聚，模块内部非常紧密，低耦合，模块之间独立或者联系不紧密）

1.19.1.2 设计模式原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即:设计模式为什么这样设计的依据)
设计模式常用的七大原则有:

1. 单一职责原则
2. 接口隔离原则
3. 依赖倒置原则
4. 里氏替换原则
5. 开闭原则
6. 迪米特法则
7. 合成复用原则

金句
设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计(OOA/D）的精要”
Scott Mavers在其巨著《Effective C++》就曾经说过:C++老手和C++新手的区别就是前者手背上有很多伤疤

1.19.1.2 单一职责原则

基本介绍
对类来说的，即一个类应该只负责一项职责。

如类A负责两个不同职责:职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2

注意事项

1. 降低类的复杂度，一个类只负责一项职责。
2. 提高类的可读性,可维护性
3. 降低变更引起的风险
4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则;只有类中方法数量足够少，可以在方法级别保持单一职责原则
    

1.19.1.3 接口隔离原则

基本介绍
1)客户端不应该依赖它不需要的接应该建立在最小的接口上口,即个类对另一个类的依赖应该建立在最小的接口上

类A通过接口Interface1依赖类B,类c通过接口lnterface1依赖英D,如果接口
lnterface1对于类A和类c来说不是最小接口那么类B和类D必须去实现他们不需要的方法。
按隔离原则应当这样处理:
将接口interfacei拆分为独立的几个接口,类A和类c分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
 

1.19.1.4 依赖倒置原则

基本介绍
依赖倒转原则(Dependence Inversion Principle)是指:

1. 高层模块不应该依赖低层模块,二者都应该依赖其抽象
2. 抽象不应该依赖细节，细节应该依赖抽象
3. 依赖倒转(倒置)的中心思想是面向接口编程
4. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类,细节就是具体的实现类
5. 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的
6. 任务交给他们的实现类去完成

应用实例

person接收消息

方式一

public class DependecyInversion {
    public static void main(String[]args) {
        Person person= new Person();
        person.getInfo(new Email());
    }
}
//电子邮件类
class Email{
    public String getInfo(){
    return "电子邮件信息";
    }

}

//完成Person接收消息的功能/方式1完成
class Person {
    public void receive(Email email ){
        system.out.println(email.getInfo());
    }
}

方式一分析

简单，比较容易想到

但是由于在receive方法里直接传入Emai,导致依赖性很强

如果要接收微信、短信的信息，就要新增类，同时person也要新增相应的接收方法

解决办法

引入一个抽象的接口IReceiver，表示接收者，这样Person类与接口IReceiver发生依赖

因为Email，微信，短信都属于接收的范围，他们各自实现IReceiver接口即可，这样就符合依赖倒置原则

方法二

public class DependecyInversion {
    public static void main(String[]args) {
        Person person= new Person();
        person.getInfo(new Email());
        person.getInfo(new Wechat());
    }
}

//定义一个接口
interface IRecevier{
    public String getInfo();
}

//电子邮件类
class Email implements IReceiver{
    public String getInfo(){
        return "电子邮件信息";
    }

}

//微信
class Wechat implements IReceiver{
    public String getInfo(){
        return "微信信息";
    }
}

//完成Person接收消息的功能/方式2完成
class Person {
    public void receive(IRecevier recevier){
        system.out.println(recevier.getInfo());
    }
}

依赖关系传递的三种方式和应用案例
1 接口传递

2 构造方法传递

3 setter方式传递

1.19.1.5 里式替换原则

oo中的继承性的思考和说明

1. 继承包含这样一层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
2. 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
3. 问题提出:在编程中，如何正确的使用继承? 里氏替换原则
    

侵入性：如A类，B类，B类继承了A，A一旦变化就会影响到B，如果A有很多的子类，一旦A变化，所有的子类可能都要受到影响，这个就是对象间的耦合性

基本介绍

1. 里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的以为姓里的女士提出的。
2. 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
3. 在使用继承时，遵循里氏替换原则,在子类中尽量不要重写父类的方法
4. 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合,组合,依赖来解决问题。.

一个程序引出的问题和思考

看下面程序

 B继承A，里面自定义了func2方法，但是无意间重写了func1方法

再执行a.func1是没有问题的

设计模式（Design pattern）代表了最佳的实践 ，可以理解为非常好用的套路。

设计模式本身是一种思想，用于解决某些简单常用需求的固定思路或代码，称之为设计模式 。

1.19.2分类

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1.19.3 创建型模式

1.19.3.1 工厂方法模式

1.19.3.1.1 工厂模式

工厂模式有3种实现方式：

1. 简单工厂模式
2. 工厂方法模式
3. 抽象工厂模式

1.19.3.1.2简单工厂模式

我们将被创建的对象称为产品，创建产品的对象称为工厂，如果创建的产品少，就只需要一个工厂类，这种模式称为简单工厂模式。

创建实例的方法为静态方法

静态工厂(SimpleFactory)：核心，负责创建所有实例，工厂类创建产品类的方法对外公开，可直接调用

抽象产品(Product)：简单工厂创建的所有对象的父类

具体产品(ConcreteProduct)：

 示例

public class Client{
    public static void main(String[] args){
    }
    //抽象产品
    public interface Product{
        void show();
    }
    //具体产品:productA
    static class ConcreteProduct1 implements Product{
        public void show(){
            system.out.println("产品1");
        }
    }
    //具体产品:productB
    static class ConcreteProduct2 implements Product{
        public void show(){
            system.out.println("产品2");
        }
    }
    final class Const{
        static final int PRODUCT_A=0;   
        static final int PRODUCT_B=1; 
        static final int PRODUCT_C=2;  
    }
    static class SimpleFactory{
        public static Product makeProduct(int kind){
            switch(kind){
                case Const.PRODUCT_A:
                    return ConcreteProduct1();
                case Const.PRODUCT_B:
                    return ConcreteProduct2();
             }
          return null;
        }
    }
}

但是简单工厂模式违背了开闭原则，重点使用工厂方法模式。

1.19.3.1.3 工厂方法模式

优点:

1. 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。
2. 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
3. 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

缺点:

1. 类的个数容易过多，增加复杂度
2. 增加了系统的抽象性和理解难度
3. 抽象产品只能生产一种产品，此弊端可使用抽象工厂模式解决。
    

 场景

1. 客户只知道工厂名，不知道具体产品名
2. 创建对象的任务由工厂完成，而抽象工厂只提供创建产品的接口

模式结构

抽象工厂(Abstract Factory):提供了创建产品的接口

具体工厂(Concrete Factory):主要是实现了抽象工厂中的抽象方法，完成具体产品

抽象产品(Product):定义了产品的规范，描述了具体产品的创建。

具体产品(Concrete Product):

1.19.3.2  抽象工厂模式

1.19.3.3 单例模式

1.19.3.3.1 单例概述与分类

模式定义

保证一个类只有一个实例，并且提供一个全局访问点

场景

重量级的对象，不需要多个实例，如线程池，数据库连接池

比如Hibernate的SessionFactoy，它充当数据存储源的代理，并负责创建Session对象。SessionFactory是重量级的，一般情况下，一个项目通常只需要一个SessionFactory就够，这是就会使用到单例模式。

单例模式有八种方式：

1. 饿汉式(静态常量)
2. 饿汉式（静态代码块)
3. 懒汉式(线程不安全)
4. 懒汉式(线程安全，同步方法)
5. 懒汉式(线程安全，同步代码块)
6. 双重检查      √
7. 静态内部类   √
8. 枚举              √

1.19.3.3.2 饿汉式(静态常量)

饿汉式（静态常量)应用实例步骤如下:

1. 构造器私有化(防止rlew )
2. 类的内部创建对象
3. 向外暴露一个静态的公共方法——getInstance

代码实现

public class singletonTest1 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}
//饿汉式(静态变量)
class singleton {
//1.构造器私有化,外部能new
    private Singleton(){

    }
//2.本类内部创建对象实例
    private final static Singleton instance = new Singleton();
//3.提供一个公有的静态方法，返回实例对象
    public static Singleton getInstance(){
        return instance;
    }
}

优缺点说明
1) 优点:这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题

2) 缺点:在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费

3) 这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用getInstance方法，但是导致类装载的原因有很多种，因此不能确定有其他的方式(或者其他的静态方法）导致类装载，这时候初始化instance就没有达到lazy loading的效果

4) 结论:这种单例模式可用，可能造成内存浪费

1.19.3.3.3 饿汉式(静态代码块)

public class singletonTest2 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}
//饿汉式(静态变量)
class singleton {
//1.构造器私有化,外部能new
    private Singleton(){

    }
//2.本类内部创建对象实例
    private static Singleton instance;
//在静态代码块中创建单例对象
    static{
        instance=new Singleton();
    }
    
//3.提供一个公有的静态方法，返回实例对象
    public static Singleton getInstance(){
        return instance;
    }
}

优缺点说明
1) 这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
2) 结论:这种单例模式可用,但是可能造成内存浪费

1.19.3.3.4 懒汉式(线程不安全) 

public class singletonTest3 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}

class singleton {
    private static Singleton instance;
//1.构造器私有化,防止外部能new
    private Singleton(){

    }
//2.提供一个静态的公有方法，当使用到该方法时，才去创建instance
//即懒汉式
    public static Singleton getInstance(){
    
        if(instance == null){
            instance=new Singleton();
        }
        return instance;
    }
}

 优缺点说明
1) 起到了Lazy Loading的效果,但是只能在单线程下使用

2) 如果在多线程下，一个线程进入了if (singleton m= null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式

3) 结论:在实际开发中，不要使用这种方式

1.19.3.3.5 懒汉式(线程安全，同步方法) 

public class singletonTest4 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}

class singleton {
    private static Singleton instance;
//1.构造器私有化,防止外部能new
    private Singleton(){

    }
//2.提供一个静态的公有方法，当使用到该方法时，才去创建instance
//即懒汉式  添加synchronized 关键字，解决线程安全问题
    public static synchronized Singleton getInstance(){
    
        if(instance == null){
            instance=new Singleton();
        }
        return instance;
    }
}

优缺点说明
1) 解决了线程不安全问题

2) 效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。方法进行同步效率太低

3) 结论:在实际开发中，不推荐使用这种方式

1.19.3.3.6 懒汉式(线程安全，同步代码块) 

public class singletonTest5 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}

class singleton {
    private static Singleton instance;
//1.构造器私有化,防止外部能new
    private Singleton(){

    }
//2.提供一个静态的公有方法，当使用到该方法时，才去创建instance
  public static Singleton getInstance(){
        if(instance == null){
//存在的问题，多线程已经进入if判断了，各个线程认为instance为null,结果每个线程都会创建一个实例对象，这些对象都不相同。已经违背了单例模式
            synchronized(Singleton.class){
                instance=new Singleton();
            }
        }
        return instance;
    }
}

优缺点说明
1) 这种方式，本意是想对第四种实现方式的改进，因为前面同步方法效率太低，改为同步产生实例化的的代码块
2) 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例
3) 结论:在实际开发中，不能使用这种方式

1.19.3.3.7 双重检查

推荐使用

既能解决线程安全的问题，也能解决效率的问题

volatile可以保证instance写入缓存和刷进内存是一个原子性操作，这样其他线程从内存读取instance就不会再读到null了。

 private static volatile Singleton instance可以保证当instance有修改后，立即将修改的值刷入主存中

public class singletonTest6 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}

class singleton {
    private static volatile Singleton instance;
//1.构造器私有化,防止外部能new
    private Singleton(){

    }
//2.提供一个静态的公有方法，加入双重检查代码，解决线程安全问题，同时解决懒加载问题
  public static Singleton getInstance(){
//第一次判断
        if(instance == null){

          synchronized(Singleton.class){
//第二次判断
                if(instance==null){
                    instance=new Singleton();
                }
            }
        }
        return instance;
    }
}

执行分析

 之后的线程，如果存在实例对象，直接在synchronized同步前的判断中就结束了，就不会进入到synchronized同步中，提高了效率，同时又实现了懒加载。

优缺点说明

1) Double-Check概念是多线程开发中常使用到的，如代码中所示，我们进行了两次if (singleton == null)检查,这样就可以保证线程安全了。
2) 这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象，也避免的反复进行方法同步.
3) 线程安全、延迟加载、效率较高
4) 结论:在实际开发中,推荐使用这种单例设计模式
 

1.19.3.3.8 静态内部类

public class singletonTest7 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.getInstance();
    Singleton instance2 = Sing1eton.getInstance();
    //instance1 与instance2 地址一样，是一个对象实例

    }
}

class singleton {
    private static volatile Singleton instance;
//1.构造器私有化,防止外部能new
    private Singleton(){

    }
//写一个静态内部类，该类有一个静态属性Singleton
    private static class SingletonInstance{
        private static final Singleton INSTANCE = new Singleton()
    }

//提供一个静态的公有方法
    public static Singleton getInstance(){
        return SingletonInstance.INSTANCE;
    }


}

特点

1. 静态内部类的外部类装载时，静态内部类不会被装载
2. 只有在静态内部类在调用getInstance时，会导致静态内部类的装载，只装载一次，静态内部类的线程是安全的（底层机制：JVM装载时是线程安全的）

优缺点说明
1) 这种方式采用了类装载的机制来保证初始化实例时只有一个线程。
2) 静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getinstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。
3) 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JⅣM帮助我们保证了线程的安全性,在类进行初始化时，别的线程是无法进入的。
4) 优点:避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

5) 结论:推荐使用.

1.19.3.3.9 枚举

public class singletonTest8 {
    public static void main(String[ ] args) {
    //测试
    Singleton instance1 = Sing1eton.INSTANCE;
    Singleton instance2 = Sing1eton.INSTANCE;
    //instance1 与instance2 地址一样，是一个对象实例

    }
}
//使用枚举实现单例
enum Singleton{
    INSTANCE; //属性
{

优缺点说明
1) 这借助JDK1.5中添加的莉举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
2) 这种方式是Effective Java作者Josh Bloch 提倡的方式

3) 结论:推荐使用

1.19.3.4  创造者工厂模式

1.19.3.5  原型模式

1.19.3.5.1  原型模式的定义与特点

原型模式的定义:

用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。

原型模式的优点:

 Java自带的原型模式基于内存二进制流的复制，在性能上比直接new一个对象更加优良。
·可以使用深克隆方式保存对象的状态，使用原型模式将对象复制一份，并将其状态保存起来，简化了创建对象的过程。

1.19.3.5.2  原型模式的结构与实现

由于Java提供了对象的clone()方法，所以用Java 实现原型模式很简单。
1.模式的结构
原型模式包含以下主要角色。

1.抽象原型类:规定了具体原型对象必须实现的接口。
2.具体原型类:实现抽象原型类的clone()方法，它是可被复制的对象。

3.访问类：使用具体原型类中的clone()方法来赋值新的对象。

结构图

 模式的实现

原型模式的克隆分为浅克隆和深克隆。

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。

深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

Java中的Object类实现了浅克隆的clone()方法，具体原型类只要实现Cloneable接口就可以实现对象的浅克隆，这里的Cloneable接口就是抽象原型类。

//具体原型类
class Realizetype implements cloneable {
    Realizetype(){
        system.out.println("具体原型创建成功!");
    }

    public object clone() throws cloneNotsupportedException {
        system.out.println(""具体原型复制成功!“);
        return (Realizetype) super.clone();
    }
}

//原型模式的测试类
public class PrototypeTest {
    public static void main(String[] args)throws CloneNotSupportedException {
        Realizetyre obj1 = new Realizetype();
        Realizetype obj2 = (Realizetype) obj1.clone();system.out.println("obj1-=obj2?" +(obj1 == obj2));
}
}

原型模式除了可以生成相同的对象，还可以生成相似的对象，如下实例。

用原型模式生成“三好学生”奖状

“三好学生”奖状，除了获奖人姓名不同，其他都一样。属于相似对象的复制，可以用原型模式创建。

public class ProtoTypecitation {
    public static void main(string[ ] args) throws cloneNotSupportedException {
    citation obj1 = new citation("张三"，"同学:在2021学年第一学期中表现优秀，被评为三好学生。"，"信息学院"");obj1.display();
    citation obj2 = (citation) obj1.clone();obj2.setName("李四");
    obj2.display();
    }
}


//奖状类
class citation implements cloneable {
    string name;
    string info;string college;
    citation(string name，string info,string college){
        this.name = name;
        this.info = info;
        this.college = college;
        system.out. println(奖状创建成功!“);
    }
    void setName(string name){
        this.name = name;
    }

    string getName() {
        return (this.name);
    }
    void display() {
        system.out.println(name + info + college);
    }
    public object clone() throws cloneNotSupportedException {
        system.out.println("奖状拷贝成功!”);
        return (citation) super.clone();
    }

 运行结果

1.19.3.5.3  原型模式的应用场景

1. 原型模式通常适用于以下场景。
2. 对象之间相同或相似，即只是个别的几个属性不同的时候。I
3. 创建对象成本较大，例如初始化时间长，占用CPU太多，或者占用网络资源太多等，需要优化资源。
4. 创建一个对象需要繁琐的数据准备或访问权限等，需要提高性能或者提高安全性。
5. 系统中大量使用该类对象，且各个调用者都需要给它的属性重新赋值。

在Spring 中，原型模式应用的非常广泛，例如 scope=prototype'、JSON.parseObject()等都是原型模式的具体应用。

1.19.3.5.4  原型模式的扩展

原型模式可扩展为带原型管理器的原型模式，它在原型模式的基础上增加了一个原型管理器PrototypeManager类。该类用HashMap保存多个复制的原型，Client 类阿以通过管理器的get(String id)方法从中获取复制的原型。其结构图如下图所示。

1.19.4 结构性模式

1.19.4.1 适配器模式

通常有两种实现适配器模式

1. 类适配器
2. 对象适配器

目前类适配器已不再使用，默认情况下采用对象适配器会使得代码更易于扩展与维护

基本思想：对现有的接口的实现类进行扩展，使其实现客户期望的目标接口

对象适配器持有现有类一个实例，并扩展其功能，实现目标接口，优先采取组合而非继承，会使得代码更利于维护。

1.19.4.1.1 类适配器

组成要素

• Target: 客户期望获得的功能接口(220V电压供电)。
• Cilent: 客户，期望访问Target接口(客户期望能有220V电压)。
• Adaptee: 现有接口，这个接口需要被适配(现有110V电压供电，需要被适配至220V)。
• Adapter: 适配器类，适配现有接口使其符合客户需求接口(适配110V电压，使其变为220V电压)。

对象适配器结构图

 Adaptee

public interface UserService{
    public Map findById();
    public List<Map> findUsers();
}

public class UserServiceImpl implements UserService {
    public Map findById(){
        Map map = new LinkedHashMap ();
        map.put("user_id", 1234);
        map.put("username",zhangsan");
        return map;
    }
    public List<Map> findUsers(){
        List<Map> list = new ArrayList<>();
        for(int i =o ; i<=10 :i++){
            Map map =new LinkedHashMap();
            map.put ( "user_id", new Random().nextInt (100000));
            map.put ("username","user"+i);
            list.add (map);
        }
        return list;
    }
}

现有UserService接口以及其实现类，并且接口的方法返回的类型是Map和List<Map>

但是现在有个需求：要求接口的方法返回的类型都是JSON(JSON就是字符串)

采用适配器模式

Target

public interface SpecUserService{
    public String findByJid();
    public String findJUsers();
}

Adapter

//基于类的继承的形式
public class SpecUserServiceAdapter extends UserServiceImpl implements SpecUserService{
    //转换
    @Override
     public String findByJid(){
//通过调用父类的方法来获取原始对象
//但这里破坏了
        Map map=super.findById();
        //转换为json,这里转换json的方式是在maven中加入google的序列化实现坐标
        String json=new Gson().toJson(map);
        return json;
    }
    @Override
     public String findJUsers(){
        //同理
    }


}

 适配器内部要持有原有对象，方式通过继承父类，调用父类方法的方式获取

但是这里违背了里氏代换原则

java要求只能单继承，如果一个A类的设计，不是为了被继承。那么其他类就不能去继承A类

但是很明显UserServiceImpl 这个类就是为了实现接口而存在的，所以强行让SpecUserServiceAdapter 继承UserServiceImpl，违背了里氏代换原则

Cilent

public class client {
    public static void main (string[] args) {
        Userservice userservice = new UserserviceImpl();
        SpecUserService specUserService = new SpecUserServiceAdapter(userService);          
        system.out.println (specUserservice.findJUsers());
}

1.19.4.1.2 对象适配器

组成要素

• Target: 客户期望获得的功能接口(220V电压供电)。
• Cilent: 客户，期望访问Target接口(客户期望能有220V电压)。
• Adaptee: 现有接口，这个接口需要被适配(现有110V电压供电，需要被适配至220V)。
• Adapter: 适配器类，适配现有接口使其符合客户需求接口(适配110V电压，使其变为220V电压)。

对象适配器结构图

 客户端直接面对适配器操作即可

案例

Adaptee

public interface UserService{
    public Map findById();
    public List<Map> findUsers();
}

public class UserServiceImpl implements UserService {
    public Map findById(){
        Map map = new LinkedHashMap ();
        map.put("user_id", 1234);
        map.put("username",zhangsan");
        return map;
    }
    public List<Map> findUsers(){
        List<Map> list = new ArrayList<>();
        for(int i =o ; i<=10 :i++){
            Map map =new LinkedHashMap();
            map.put ( "user_id", new Random().nextInt (100000));
            map.put ("username","user"+i);
            list.add (map);
        }
        return list;
    }
}

现有UserService接口以及其实现类，并且接口的方法返回的类型是Map和List<Map>

但是现在有个需求：要求接口的方法返回的类型都是JSON(JSON就是字符串)

采用适配器模式

Target

public interface SpecUserService{
    public String findByJid();
    public String findJUsers();
}

Adapter

public class SpecUserServiceAdapter implements  SpecUserService{
//适配器内部要持有原有对象，方式通过构造器来传值
    private UserService userService = null;
    //构造方法 用于赋值
    public SpecUserServiceAdapter(UserService userService ){
        this.userService =userService;
    }
    //转换
    @Override
     public String findByJid(){
    //先调用原始的接口实现类的方法得到原始的数据对象
    //转换：将map转换为json格式
        Map map=userService.findById();
        //转换为json,这里转换json的方式是在maven中加入google的序列化实现坐标
        String json=new Gson().toJson(map);
        return json;
    }
    @Override
     public String findJUsers(){
        //同理
    }


}

 适配器内部要持有原有对象，方式通过定义构造器来传原始对象

Cilent

public class client {
    public static void main (string[] args) {
        Userservice userservice = new UserserviceImpl();
        SpecUserService specUserService = new SpecUserServiceAdapter(userService);          
        system.out.println (specUserservice.findJUsers());
}

 1.19.4.1.3 适配器模式总结

优点

• 可以让任何两个没有关联的类一起运行。
• 提高了类的复用，可以一致化多个不同接口。
• 将现有接口实现类隐藏，增加了类的透明度。
• 灵活性高，可自由适配。

缺点

• 过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
• 某些适配工作可能非常困难，例如让房子飞起来。
• 当我们有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。
   

上一篇：1.18Java-线程、锁、线程间通信

下一篇：1.20Java-网络编程