设计模式Java实战

一、前置

1.1 目的

1、写出好的代码，个人认为依次重要程度为：

• 健壮性

  • 个人理解为最重要的之一，好的代码，首先是无bug代码

  • 代码中，常见可能引起问题的点（重要程度不分先后）：

    • 性能：并发会不会存在问题；并发度大小（大了可能对下游压力过大，提前对其好SLA）；是否需要异步处理（写OP日志、推送消息等）

    • 降级、兜底：下游接口拿不到数据或不可用，产品侧是否有兜底数据、技术侧是否有兜底方案

    • 限流：对上游是否需要限流，保护我们的服务

    • 数据量评估：数据量增大，甚至极端场景下，会不会有慢查询，索引是否合理

    • 幂等：消息是否可能重复

    • 一致性：上下游的状态是否一致（eg：服务A将任务状态置为终态，如果上游系统B有业务动作依赖A任务的状态，那A也要告诉上游B任务终态了。否则上游B发现下游A的任务一直未终态，他们可能有自己的重试机制等）

    • 主从延时：写完读

    • 接口异常：是否强依赖、重试等

    • 中间件异常：是否强依赖redis，如果redis短期不可用，业务上是否可以降级跳过redis的卡控逻辑。使用中间件生成单据号，如果中间件短时间不可用，是否有备用方案生成单据号等

    • 边界条件：while循环为了防止死循环，结合业务要设置最大的循环次数；终止条件最好是>=或<=，防止并发时跳过了；日期判断或者日期作为查询条件也要特别注意；集合get(0)首先是npe其次是集合的所有元素是否都一致，不一致就不能拿第一个元素的内容去赋值；switch要有default；if要和else if（） else if（）最好加上条件，避免落到if else中

    • 数据库：字段类型（是否大小写敏感）、大小（是否需要截断）、update是否需要updateSelective、查询in（为空）则可能查询全量数据

    • 参数校验：api接口一定不要相信传参

    • 事务失效问题：rpc写和本地写、以及其它

    • 单位问题：精度、元分。kg和mg等

    • npe问题：常见可能造成npe的点

    • 锁的释放：超时时间是否设定、异常流程是否释放锁

    • /0

    • list转map，list的字段可能重复，作为map的key则可能Duplicate key异常

• 可读性

  • 代码终究是给人读的
  • 主要是代码的整洁之道那些内容

• 可复用性

  • 不写重复的代码
  • 高内聚低耦合（模块内部内聚，模块之间解耦）
  • eg：网关层封装的查询方法应该做的事项有：
    封装并发（调用方只需要传入所有的skuIdList，gateway自己按照200、200拆分sku并发查询）
    返回数据要自定义（如果rpc调用的返回对象为集合List其中A有很多的属性，可能我们并不关心，那么gateway就需要自己定义对象DTO，属性只有几个我们关心的字段即可）

• 可扩展性

  • 设计模式的内容
  • eg：需求需要对规则进行新增、删除，只需要调整枚举类，不需要修改现有代码逻辑

• 兼容性：尤其是字段调整，要遵循新增而非删除（eg：skuId变为skuIdList，一般是新增字段，然后做好上线过度）

2、设计原则、设计模式等，目的都是为了写“好”代码

1.2 面向对象

1、看似面向对象，实则面向过程的做法

• 滥用get、set方法，违反了面向对象的特征：封装。除非需要否则，不要给属性定义setter

• Constants常量类：不要单独设计此常量类。好的 做法：哪个类用的用到了某个常量，在此类汇总定义即可

  否则，不易维护：改一个常量，影响太多地方，不能轻易修改；不易复用：要在另一个项目中复用本项目的某类，此类中又依赖Constants，相当于把整个Constants都一并引入了

2、面向对象编程步骤

以：对接口进行鉴权为例

• 分析实现步骤

  • 调用方进行接口请求的时，将URL、useId、pwd、ts时间戳拼接在一起传递过来；通过加密生成token；并将token、useId、ts拼接在URL中传递
  • 接收到请求后，解析URL，获取token、useId、ts
  • 校验ts和当前时间，是否在合理的时间窗口内（生成的ts和当前时间间隔1min则认为token失效），失效则拒绝
  • 通过useId去缓存或db中获取pwd，通过同样的方式生成token，与调用传递的token对比，不一致则拒绝

• 划分职责，识别出有哪些类

  • 如果是大需求，涉及多个模块，则需要先把需求按照模块划分。eg：逆向计划自动建单分为（触发模块、获取可退sku、计算可退量、合单、下发、回掉等多个模块）

  • 将需求转换为每个模块要实现的内容；并拆解为小的功能，一条一条列出来，这里以接口鉴权为例

    1、把URL、useId、pwd、ts拼接为子串

    2、通过字符串，加密生成token

    3、将useId、token、ts形成新的url

    4、解析url，获取ts、useId、token

    5、根据useId去存储介质中获取pwd

    6、根据ts判断token是否在有效的窗口内

    7、根据获取的pwd同样方式生成token，比较和传递过来的token是否一致

  • 其中1、2、6、7和token相关，负责token的生成和比对 ； 3、4和URL相关，负责url的拼接、解析等；5是单独的获取pwd。

    这样，我们就定义了三个主要的类：AuthToken、Url、UseStorage

  • 这里体现了高内聚（将小的功能点理清楚到底属于哪个类，相同的都放在一起），低耦合（不属于这个类的属性和方法，则不要放在这个类里，比如URL信息，useId不应该属于Token，不要作为他的属性）

• 定义类 和 属性、方法

  • AuthToken：定义属性和方法：

    • 1和2：createToken（String url， Long useId，String pwd）
    • 6：isExpireed（Long ts）
    • 7：match（String token）

  • ApiUrl

    • 3：buildUrl（）

    • 4：getTokenFromUrl(String url)

      ：getUseIdFromUrl(String url)

      ：getTsFromUrl(String url)

• 定义类和类之间的交互关系（继承、实现、聚合、组合、依赖等）

• 思考：

  我理解的面向对象编程，就好比要外出旅游，将这个需求分为：衣食住行四个模块

  • 衣：带什么衣服（上衣、裤子等）
  • 行：是坐火车还是飞机，如果是坐火车，如何去火车站等
  • 住：是住酒店还是民宿，住的地方和旅游景点的远近、交通的便利等

  就是在未出发之前，衣食住行模块都想好，方法也想好（先公交、再火车），类之间如何衔接（对应类之间的关系）。然后按照这些去旅游。

  面向过程编程，则是准备去旅游。

  • 行模块：早上起来看有飞机航班么，没有则坐火车，最近的一趟火车，出发。
  • 住：到了目的地，随便找个地方先住下来

  类似这种，我理解为面向过程。

1.3 接口和抽象类

1、什么时候使用接口

• 需要将接口和实现相分离，封住不稳定的实现，暴露稳定的接口
• 上游系统面向接口编程，这样接口实现发生变化时，上游系统代码基本不需要改动。降低了代码的耦合性
• 提升了扩展性

2、要用接口和抽象类时，选择哪个

• 要表示is a（三角形是图形，圆形是图形—），同时目的是为了解决代码的复用性，则使用抽象类；
• 表示has a，并且为了解耦，而非代码的复用，则使用接口

3、基于接口编程注意事项

• 函数名不要暴露实现细节，否则后续需求变化，名称可能词不达意甚至描述有误。所以尽量抽象。eg：uploadPicture而非uploadPicture2Yun
• 封装具体的实现细节。

eg：sku查询算法值（不同的sku对应的供货链路不同，不同的供货链路，对应查询不同的算法类型值），则queryAlQty(Integer supplyType,Long skuId)不如

queryAlQty(Long skuId)：内部封装了查询供货链路。

二、七大设计原则

（设计模式本身的原则）

2.1 单一职责

1、概念：一个类只负责一项职责。如果负责了多个，就需要拆分成多个类

2、举例：OrderRepository中不要涉及对SkuDO的CRUD

3、作用：

• 不会使一个类过于庞大；
• 可维护性：改了Order相关内容不会影响Sku相关内容，否则可能会相影响；
• 高内聚（提高代码，缩小功能改动导致的代码改动范围）。

4、编码实现

• 不符合单一职责的代码

原因：显然飞机不能一直在公路上跑。应该拆分为陆、海、空三个单一职责的交通工具类

@Data
public class Single {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("飞机");
    }

    static class Vehicle{
        public void run(String vehicle) {
            System.out.println(vehicle + "一直在公路上跑");
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 符合单一职责的类

@Data
public class Single {
    public static void main(String[] args) {
        Vehicle1 vehicle1 = new Vehicle1();
        vehicle1.run("汽车");

        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.run("飞机");
    }

    static class VehicleRoad{
        public void run(String vehicle) {
            System.out.println(vehicle + "在公路上跑");
        }
    }

    static class VehicleAir{
        public void run(String vehicle) {
            System.out.println(vehicle + "在天上非");
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

5、思考

逆序计划流程 = 1触发建单 + 2【触发oih + 落sku + 计算可退量 + 合单并下发+回掉】

做了RDC退、协同退、PC退之后，发现流程2是完成可以复用。但是流程1，不同的触发源尤其是RDC退和PC退，很多代码都写在一个类中，实际上违背了单一职责。改动PC退的流程1代码有可能影响RDC退。

6、如何定义一个类，以及如何根据单一职责，判断一个类是否需要拆分

public class UserInfo {
    private Long userId;
    private String name;
    private Long createTime;
    private Long lastLoginTime;
    
    private String email;
    private Long phoneNo;
    
    private String province;
    private String city;
    private String region;
    private String detailAddress;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 可以先第一版比较粗的类UserInfo。随着业务迭代持续重构：比如后续有了物流业务，则用户的地址信息可以抽取出来独立类；

  比如：后续有了论坛、金融等业务需要对用户进行登录校验，则可以将email、phone拆出来独立类

• 代码属性过多、代码的行数过多（>200）、代码的方法过多，则需要考虑是否对类进行拆分

• 依赖的其它类过多。为了低耦合，考虑是否拆

• 私有方法过多，为了复用性，可以抽取出来放到新类中作为public方法

• 类已经找不到合适的词来形容了，职责定义已经不清晰了，可拆

• 类中大量的方法都在对某几个属性进行操作，则可以考虑将这几个属性抽取出来单独成一个类

2.2 接口隔离原则

1、概念：接口的调用者，不应该被强迫依赖它不需要的接口

2、作用：

• 提高灵活性:一个类是可以同时实现多个接口的，所以将一个臃肿的接口分割为若干个小接口，通过小接口的不同组合可以满足更多的需求
• 高内聚

3、满足接口隔离原则code

• "接口"含义：一个接口中的多个方法

  • 不满足接口隔离

    public interface UserService{
        boolean register(String phone, String pwd);
        boolean login(String phone, String pwd);
        UserInfo getUserInfo(String phone);
        boolean deleteUser(String phone, String pwd);//删除用户
    }
    
    public UserServiceImpl implements UserService{
      //---
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10

    正常情况下，用户在调用UserService接口中的方法时，一般不会也不允许调用deleteUser方法，只会用到CRU功能。

    根据接口隔离原则：接口的调用者，不应该强迫依赖他不需要的接口即deleteUser方法

  • 满足接口隔离

    后端管理系统ManagerUserImpl才需要CRUD功能

    public interface UserService{
        boolean register(String phone, String pwd);
        boolean login(String phone, String pwd);
        UserInfo getUserInfo(String phone);
    }
    
    public interface ManagerService{
        boolean deleteUser(String phone, String pwd);//删除用户
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9

    public class UserServiceImpl implements UserService{
    		//CRU功能---
    }
    
    public class ManagerServiceImpl implements UserService, ManagerService{
    		//CRUD功能---
    }
    1
    2
    3
    4
    5
    6
    7

• “接口”的含义：可以是接口中的某个方法

  • 不满足接口隔离

    public class Statistics {
        private Long max;
        private Long min;
        private double avg;
        private Integer count;
        
        public Statistics count(Collection data) {
            Statistics statistics = new Statistics();
            // 计算逻辑
            return statistics;
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12

    count函数功能不单一，包含了max、min、count、avg等多个功能。

    按照接口隔离原则：函数的设计功能单一，不要将多个不同的功能逻辑在一个函数中

  • 满足接口隔离

    将count方法拆分为max()、min()、avg()等方法。如何要想使用复合计算则可以直接使用

    LongSummaryStatistics statistics = new LongSummaryStatistics();
    statistics.accept(1);
    statistics.accept(2);
    statistics.accept(3);
    1
    2
    3
    4

2.3 依赖倒转原则

1、概念：高层模块（调用者）不要依赖低层模块（被调用者），二者应该通过抽象（接口)互相依赖

eg：Tomcat：高层模块，编程的Web应用程序（低层模块）只需要部署在Tomcat容器下，便可以被Tomcat调用运行。

Tomcat不依赖Web应用程序，只要Web应用程序满足Servlet接口规范，那么无论你是啥Web应用程序，都可以在Tomcat上运行。

Tomcat和Web应用程序通过Servlet接口互相依赖

2、作用：通用性好、扩展性好

3、控制翻转IOC

• 定义：原本是程序员自己控制整个程序的执行，使用框架之后，框架来控制程序流程。流程的控制权从程序员反转到了框架

• 举例：

  • 程序员控制程序执行

    public class UserServiceTest {
        public static boolean needTest() {
            return true;
        }
    
        public static void main(String[] args) {
            if (needTest()) {
                System.out.println("do test");
            } else {
                System.out.println("not do test");
            }
        }
    }
    
    public class SkuServiceTest {
        public static boolean needTest() {
            return false;
        }
    
        public static void main(String[] args) {
            if (needTest()) {
                System.out.println("do test");
            } else {
                System.out.println("not do test");
            }
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27

  • 框架控制程序执行

    //这里类似模板设计
    public abstract class BaseTest {
        public boolean needTest();//预留扩展点
    
        public void run() {
            if (needTest()) {
                System.out.println("do test");
            } else {
                System.out.println("not do test");
            }
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12

    public class UserServiceTest extends BaseTest{
        @Override
        public static boolean needTest() {
            return true;
        }
    }
    
    public class SkuServiceTest extends BaseTest{
        @Override
        public static boolean needTest() {
            return false;
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13

    public class ApplicationLoader {
        public static void main(String[] args) {
            SpringApplication.run(ApplicationLoader.class, args);
            
            private static final List<BaseTest> LIST = new ArrayList<>();
            for (BaseTest test : LIST) {
                test.run()
            }
        }
    
        public void register(BaseTest test) {
            LIST.add(test);
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14

ApplicationLoader.register(new UserServiceTest());
ApplicationLoader.register(new UserServiceTest());

1、在BaseTest预约扩展点
2、不同的Test类，实现自己业务相关的功能（是否needTest），不需要再写用于执行流程的main函数了
3、将不同的Test类，添加到ApplicationLoader
4、在ApplicationLoader启动的时候执行main函数，会遍历执行所有Test的run方法
程序的执行（main函数执行），由程序员控制（写在不同Test中），反转到框架控制（统一register到Application，它启动的时候，会执行所有Test的run方法）
1
2
3
4
5
6
7
8

4、依赖注入DI

• 定义：

  A类中使用B类，不同new B()的方法创建b，而是将B在外部创建好后，通过new A(b)构造函数、函数参数func(B b)、set属性等方式传递（注入）给A类使用

• 和控制反转的关系：

  控制反转不是具体的实现技巧，而是一种用于指导框架设计的思想。而DI则是具体的编码技巧，是IOC的具体实现

• 依赖注入 和 非依赖注入

  • 背景：

  Notification类负责将商品的促销、验证码消息等给用户。它依赖MessageProductor生产者类发送消息

  • 非依赖注入
    • B类（MessageProductor）

  public class MessgaeProductor {
      public boolean send(String msg) {
          //
      }
  }
  1
  2
  3
  4
  5

  ​ A类（Notification）

  public class Notification {
      private MessgaeProductor messgaeProductor;
      public Notification() {
          this.messgaeProductor = new MessgaeProductor();//A类中使用B类，通过new方式在A类中创建
      }
      
      public void sendMessage(String msg) {
          this.messgaeProductor.send(msg);
      }
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10

  Notification notification = new Notification();
  notification.sendMessage("msg");
  1
  2

  • 依赖注入

    • B1、B2（MessgaeProductor接口实现类）

    public interface MessgaeProductor {
        public boolean send(String msg);
    }
    1
    2
    3

    // B1:短信生产类
    public class SmsProductor implements MessgaeProductor{
        @Override
        public boolean send(String msg) {
            //发送短信
        }
    }
    
    // B2:微信消息生产类
    public class WeChatProductor implements MessgaeProductor{
        @Override
        public boolean send(String msg) {
            //发送微信信息
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15

    • A（Notification类）

    public class Notification {
        private MessgaeProductor messgaeProductor;
        public Notification(MessgaeProductor messgaeProductor) {
            this.messgaeProductor = messgaeProductor;//A类中使用B类，通过构造器将b注入A中
        }
    
        public void sendMessage(String msg) {
            this.messgaeProductor.send(msg);
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10

    • 外部

    public class Demo {
        public static void main(String[] args) {
            DaxiangProductor messgaeProductor = new DaxiangProductor();//创建对象b
            Notification notification = new Notification(messgaeProductor);//通过构造函数，将b依赖注入A类中
            notification.sendMessage("msg");
        }
    }
    1
    2
    3
    4
    5
    6
    7

5、依赖注入框架

• 产生背景

  • 对比依赖注入和非依赖注入，发现new B()的动作，只不过从在A类中new，变成了在更上次外部类Demo中new，还是需要程序员自己实现
  • 一个项目可能有成百上千个类的创建和依赖注入，如果全部都由程序员自己实现，将变得复杂容易出错
  • 对象的创建和依赖注入动作本身和业务不相关，完全可以抽象成框架来自动完成

• 常见的依赖注入框架：Spring、Google的Guice

• 作用

  • 参考背景
  • 只需要通过依赖注入框架提供的扩展点，简单配置一下虽有需要创建的类对象、类与类之间的依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等

• 举例

  public class A{
      @Resource
      private B b;
      public static void main(String[] args) {
          b.send("msg");
      }
  }
  1
  2
  3
  4
  5
  6
  7

通过Spring框架提供的扩展点-后置处理器，@Resource private B b，就可以实现B的创建和生命周期的管理，同时后置处理器通过set的将b注入A类中

2.4 里氏替换原则

1、概念： 子类对象能够替换程序中父类对象出现的任何地方，并且保证原来的逻辑行为不变且正确性不被破坏。

一句话：子类重写父类的方法，不要改变原有方法的逻辑（方法声明、输入、输出、对异常的处理等约定）

2、作用：指导子类如何设计，不改变父类的逻辑

3、子类重写父类方法时，常见的违背里氏替换原则的场景有

• 违背父类的输入

  父类输入Integer是整数，子类输入Integer要求是正整数

• 违背父类的输出

  父类catch代码块中return的是空集合，子类重写方法中catch块中return的是null

• 违背父类方法的声明

  父类sortBySkuId，查询结果按照skuId排序。子类sortBySkuId查询结果按照实时销量排序了

• 违背父类异常的处理

  父类valid参数时，不满足时，抛出的是ArguementNullException。子类抛出的是illeagalException

4、思考：

2.5 开闭原则

1、概念：一个模块、类、方法对修改关闭，对扩展开放。添加一个新功能，应该是新增代码，而非 修改代码。

补充：有的时候新增功能，是改变了类，对于类而言是被改变了，但是对于方法来说没有改变，也满足开闭。

2、作用：提升代码的扩展性，23种设计模式的目的都是为了满足开闭原则。尽量让修改更为集中、给小、更上层。核心的、复杂的逻辑尽量不修改少修改

3、编码：可以参考RuleExpressHelper，通过遍历规则枚举类，将枚举类code、desc提前put至Map map1,Map map2，其内部提供了将"lo&&s"转换lo、s，再通过map1转换为[1,2]，将[1,2]转换为"lo&&s"，将"lo&&s"转换为[“小于OR可以修改”,“锁库不可更改”]等，规则表示之间的转换方法。这样新增规则时，只需要对应新增枚举类即可

4、如何做到满足开闭原则

• 业务层面：扩展意识、抽象意识很重要

  • 多想下，这块逻辑，后续会有哪些需求变更，设计代码结构的时候，可以提前预留好扩展点，以便将来改动小，新的代码可灵活的插入

    eg1：规则中心，现有n个规则，如果后续新增规则，是不是不改变现有代码逻辑实现，仅仅通过新增枚举类就可以实现页面的CRUD。

    eg2：退供下发执行，后续会不会有逆向调拨下发执行。可以提前设计下发逻辑，抽象出接口。

  • 但是对于未来不确定的功能点，当下没必要过度设计，后续持续重构即可

• 技术层面：提升代码的可扩展性即基于接口编程、设计原则、设计模式（策略、模板、状态、装饰着、职责链等）

  感触最深的就是策略模式，定义行为（接口方法），新增功能，只需要新增对应的新实现，不需要改动原本的行为实现

2.6 不要重复原则

1、常见重复场景

• 实现逻辑重复：代码完全一样。

  eg：可能是不同的人开发，不知道有这个功能的代码，场景的是枚举定义一样、网关定义一样

• 功能语义重复

  • 代码不一样了，但是两个函数是一样功能。

    eg：checkAddressIsVali()和isValidAddress（）

  • 同一个功能的枚举类，定义了多个。

    eg：逆向计划中，任务的触发源类型：OriginTypeEnum 和 TriggerSourceEnum。这样以后枚举内容修改了，多处都要修改，否则有问题

• 代码重复执行

  已经在request中校验了poiId不能为null，又在构造criteria的时候，再次校验if(request.getPoiId() != null)

  对于这种情况，个人建议是可以多次校验的，因为不排除某天，入参request中允许这个字段为null了

2、如何提升代码的复用性

• 高内聚、低耦合

  大而全的类，依赖它的代码就多。进而增加了代码的耦合度，影响代码的复用。粒度越小的代码，通用性越好（DateUtil中）。越容易被复用

• 业务和非业务逻辑分离

  越是和业务无关的代码，越容易复用。

  eg：生成单据号、查询仓、品类、日期

• 代码下沉

  • 下沉的代码尽量通用。

    eg：根据仓id和skuIdList查询sku信息，方法的内部实现封装了并发查询逻辑。

• 继承、多态、抽象、封装

  • 封装：同上代码下沉。即使后续，下游rpc接口只允许sku 20个批量查询，调用此查询方法方也无需感知

  • 继承：公共代码抽取到父类，子类复用父类的方法和属性。

    eg：模板模式，通用的都抽取到父类，不同的继承，实现自己具体内容

  • 多态：使用多态可以动态的复用一段代码的部分逻辑。

    eg：Collection接口的通用方法，集合都可以使用

  • 抽象：越抽象、越不依赖具体实现的代码，越容易复用

    eg：入参为List，复用性高于ArrayList

    eg：send（HtmlRequest req），复用性不如send(String address, Byte[] data)。因为后续数据，可能服务于别的发送，不仅仅是html的发送

• 复用意识：

  • 设计一个方法的时候，要把它想象成类似于对外提供的API方法那样的复用性（不同方、不同业务都可能会调用你）
  • 多思考，编写的这部分代码是否可以抽取出来，作为一个独立的方法提供给其他地方使用

2.7 迪米特最少知道法则

1、定义：一个对象应该对其他对象有最少的了解，即最小知道。或只是直接的朋友交流

• 直接朋友：出现在类属性、方法入参和出参中的类
• 间接朋友：出现在局部变量的类，和他们的交流（使用）就会违背迪米特法则

2、作用：低耦合、高内聚

• 高内聚、单一职责原则：相近功能放在一个类中，不相近的功能不放在一个类中。相近的功能往往会被同时修改，这样改动点比较集中
• 低耦合：类和类之间的关系简单清晰，一个类的改动，不会或很少会导致依赖它的类也需要跟着改动
  • eg：基于接口编程，接口内部实现类变化了，但是对外提供的api不会变
  • eg：接口隔离，接口被拆为更细化的接口。不拆分之前接口影响多个依赖方，拆分成多个更细的接口后，某个点-对应更细接口的变动，影响的依赖方更少

3、代码：

• 背景：公司，让部门经理，打印此部门的员工姓名

• 违反迪米特法则的设计

  Employee作为局部变量出现在Company中，属于Company的间接朋友，违反了迪米特

  /**
   * 公司
   */
  public class Company{
      @Resource
      private Manager manager;
  
      public void printEmployee(String departmentName) {
          List<Employee> employeeList = manager.getAllEmployeeInfoByDepartmentName(departmentName);
          for (Employee e : employeeList) {
              System.out.println(e.getName());
          }
      }
  }
  
  /**
   * 部门经理
   */
  public class Manager{
      public List<Employee> getAllEmployeeInfoByDepartmentName(String departmentName) {
          // 内部实现：获取员工信息
      }
  }
  
  /**
   * 员工
   */
  public class Employee{
      private String name;
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30

• 符合设计

  /**
   * 公司
   */
  public class Company{
      @Resource
      private Manager manager;
  
      public void printEmployee(String departmentName) {
          manager.printEmployee(departmentName); //Company之和直接直接朋友Manager交流
      }
  }
  
  /**
   * 部门经理
   */
  public class Manager{
      public void getAllEmployeeInfoByDepartmentName(String departmentName) {
          // 1.获取员工信息(Manager内部实现)
          List<Employee> employeeList = getAllEmployeeInfoByDepartmentName(departmentName);
          // 2.打印员工姓名（Manager内部实现）
          printEmployeeName(employeeList);
      }
  }
  
  /**
   * 员工
   */
  public class Manager{
      private String name;
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30

三、23种设计模式

3.1创建型：创建对象

单例、工厂、建造者

3.1.1 单例模式

定义

一个类只允许创建唯一一个对象。这里唯一性作用的范围是进程

最佳实践

public class SkuDTO {

    private SkuDTO(){}

    private static class SkuDTOHolder {
        private static final SkuDTO INSTANCE = new SkuDTO();
        //静态内部类不会再外部类被JVM加载到内存的时候一并被加载。什么时候调用什么时候加载，解决了饿汉问题
        //JVM本身保证了SkuDTO只会在被类加载器加载时初始化一次，所以是线程安全的
    }

    public static SkuDTO getInstance() {
        return SkuDTOHolder.INSTANCE;
    }

    public static void main(String[] args) {
        for (int i = 0; i < 100; i++) {
            new Thread(
                    () -> System.out.println(getInstance().hashCode())//都是同一个对象
            ).start();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

• 缺点：可以被反射。最完美的方式是枚举，枚举有构造方法，但是通过反射创建对象即newInstance的时候，会判断如果类型是枚举类型会报错

• 优点：外部类SkuDTO被加载的时候不会创建INSTANCE实例。只要调用getInstance()方法的时候才会去创建实例。满足懒加载

  JVM保证了INSTANCE的唯一性、线程安全性

场景

• 表示全局唯一类

  • 配置类、ID生成器类等

• 处理共享资源访问冲突（写日志、共享数据库连接池等）

  eg

  • 复现：同时写日志到txt文件中，可能出现内容被覆盖的情况。原因：多线程并发写的时候，线程1和线程2都创建了FileWriter实例，获取到相同的pos待写入位置，都是从这个位置写入，造成内容覆盖

• 解决：线程1和2使用单例模式创建FileWriter，FileWriter本身是线程安全的，其内部实现了对象级别的锁即相同的FileWriter实例，在写操作是线程安全的，不会被覆盖。

  public void write(String str, int off, int len) throws IOException {
          synchronized (lock) {
              char cbuf[];
              if (len <= WRITE_BUFFER_SIZE) {
                  if (writeBuffer == null) {
                      writeBuffer = new char[WRITE_BUFFER_SIZE];
                  }
                  cbuf = writeBuffer;
              } else {    // Don't permanently allocate very large buffers.
                  cbuf = new char[len];
              }
              str.getChars(off, (off + len), cbuf, 0);
              write(cbuf, 0, len);
          }
      }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15

线程级别的单例

public class IDGenerator {
    private static final AtomicLong id = new AtomicLong(0);
    private static final ThreadLocal<IDGenerator> tl = new ThreadLocal<>();
    
    public IDGenerator getInstance() {
        tl.set(new IDGenerator());
        return tl.get();
    }
    
    public Long getId() {
        return id.incrementAndGet();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

• 同一个线程获取到的对象实例是相同的，不同线程获取到的不同。属于多例

缺点

• 单侧不友好，全局变量可能会被修改，造成测试结果相互影响问题
• 其他

为了保证全局唯一，除了单例外，我们还可以使用工厂模式来实现

3.1.2 工厂模式（简单工厂）

场景1：解析配置

将不同后缀的配置文件解析成类

• 根据文件路径x.x.Redis.properties | x.x.MySQL.yaml，创建properties 后缀和yaml后置对应的Parse解析类，解析文件内容成对象

• 代码实现

public class Config{
    public Config load(String configFilePath) {
        // 1.获取配置文件后缀
        String fileSuffix = getFileSuffix(configFilePath);//(返回properties、yaml、xml等)
        
        // 2.根据后置，创建对应的解析类
        Configparser parser = createConfigParser(fileSuffix);
        
        // 3.解析文件内容
        return parser.parse(fileSuffix);
    }
    
    public Configparser createConfigParser(String fileSuffix) {
        Configparser parser;
        if ("xml".equalsIgnoreCase(fileSuffix)) {
            parser = new XmlConfigparser();
        } else if ("yaml".equalsIgnoreCase(fileSuffix)) {
            parser = new YamlConfigparser();
        } else if ("properties".equalsIgnoreCase(fileSuffix)) {
            parser = new PropertiesConfigparser();
        }
        return parser;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

• 优化1：createConfigParser显然不属于Config类的内容。为了满足高内聚低耦合，需要将createConfigParser方法抽取到独立类中。这个类专门负责Configparser的创建，这个类就是简单工厂类

public class ConfigparserFactory{
    public Configparser createConfigParser(String fileSuffix) {
        Configparser parser;
        if ("xml".equalsIgnoreCase(fileSuffix)) {
            parser = new XmlConfigparser();
        } else if ("yaml".equalsIgnoreCase(fileSuffix)) {
            parser = new YamlConfigparser();
        } else if ("properties".equalsIgnoreCase(fileSuffix)) {
            parser = new PropertiesConfigparser();
        }
        return parser;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

• 优化2：

上述代码每次createConfigParser都会new一个新的Configparser对象。我们可以提前将Configparser对象创建好放到map中缓存起来，当调用createConfigParser方法时，直接从缓存中拿去。

public class ConfigParserFactory {
    private static final Map<String, Configparser> map = new HashMap<>();
    static {
        map.put("xml", new XmlConfigparser());
        map.put("yaml", new YamlConfigparser());
        map.put("properties", new PropertiesConfigparser());
    }
    
    // 这里Configparser是接口，XmlConfigparser是接口实现类
    public Configparser createConfigParser(String fileSuffix) {
        return map.get(fileSuffix);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

1、创建名称特点：create、getInstance、newInstance、valueOf、of、as

2、优点：当新增了YmlConfigparser解析类，只需要实现Configparser接口重写parse方法即可，然后将其添加到map中。满足开闭原则

场景2：解析表达式

规则中心定义卡控最大售卖量规则，规则解析

1、规则枚举类

@Getter
@AllArgsConstructor
public enum RuleExpEnum{
    NOT_ALLOW(1,"n","不允许修改"),
    ALLOW(2,"a","允许修改"),
    OR_MODEL(3,"o","修改值大于等于补货算法可修改");
    public  final int value;
    public  final String rule;
    public  final String desc;
}
1
2
3
4
5
6
7
8
9
10

2、使用场景

• 前后端交互：前端传[1,2,3]，后端需要解析为[“n”,“a”,“o”]
• 前后端交互：后端查db数据为[“n”,“a”,“o”]，需要展示为[“不允许修改”,“允许修改”,“修改值大于等于补货算法可修改”]

3、简单工厂类

@UtilityClass
public class RuleExpFactory {
    private static final Map<Integer, String> val2RuleMap = new HashMap<>();
    private static final Map<String, Integer> rule2ValMap = new HashMap<>();
    private static final Map<String, String> rule2DescMap = new HashMap<>();

    private static final String AND = "&&";

    static {
        for (RuleExpEnum ruleExpEnum : RuleExpEnum.values()) {
            // 1
            int value = ruleExpEnum.getValue();
            // "n"
            String ruleExp = ruleExpEnum.getRule();
            // "不允许修改"
            String desc = ruleExpEnum.getDesc();

            val2RuleMap.put(value, ruleExp);
            rule2ValMap.put(ruleExp, value);
            rule2DescMap.put(ruleExp, desc);
        }
    }

    /**
     * 1.将n&&o -> "不允许修改且修改值大于等于补货算法可修改"
     * 2. 将o  -> "修改值大于等于补货算法可修改"
     *
     * @param ruleExp 规则表达式"n"
     * @return        规则desc"不允许修改"
     */
    public String rule2Desc(String ruleExp) {
        if (StringUtils.isBlank(ruleExp)) {
            return StringUtils.EMPTY;
        }
        List<String> ruleList = Splitter.on(AND).splitToList(ruleExp);
        return ruleList.stream().map(rule2DescMap::get).collect(Collectors.joining("且"));
    }

    /**
     * 1.将[1,2] -> "n&&a"
     * 2. 将[1]  -> "n"
     *
     * @param valueList  [1,2,3]
     * @return          "n&&a&&o"
     */
    public String value2Rule(List<Integer> valueList) {
        if (CollectionUtils.isEmpty(valueList)) {
            return StringUtils.EMPTY;
        }
        return valueList.stream().map(val2RuleMap::get).collect(Collectors.joining(AND));
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

• 优点：

  • 原本实现是：使用StringBuilder进行append

  StringBuilder sb = new StringBuilder();
  if(Objects.equals(rule,"a")) {
      sb.append("允许修改")
  } else if(Objects.equals(rule,"n")) {
      sb.append("且");
      sb,append("不允许修改")
  } else if () {
  
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9

  • 这种方式缺点很明显，当新增了规则rule，则需要再新增else if判断，再添加desc，不满足开闭原则。
  • 如果规则rule很多，则代码充斥着大量的else if分支判断

实战-Calendar类

1、创建Calendar实例

 Calendar instance = Calendar.getInstance();
1

2、简答工厂模式

private static Calendar createCalendar(TimeZone zone,Locale aLocale){//这里zone和aLocale（zh_CN）都是默认值
        Calendar cal = null;
        //根据地区的语言和国家来判断日历类型
        if (cal == null) {
            if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
                cal = new BuddhistCalendar(zone, aLocale);
            } else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja"
                       && aLocale.getCountry() == "JP") {
                cal = new JapaneseImperialCalendar(zone, aLocale);
            } else {
                // 其他情况一律返回公历
                cal = new GregorianCalendar(zone, aLocale);
            }
        }
        return cal;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

为什么说这是一种简单工厂模式呢？

因为静态createCalendar() 创建实例时，根据该方法传入的参数来返回对应的 Calendar 实现类，符合工厂模式的思想（类似场景1）

总结：

当代码中存在大量if - else，根据A获取|创建B的场景，则可以考虑使用简单工厂模式

3.1.3DI依赖注入

定义

相当于一个大型工厂，负责在程序启动时，根据各种配置信息，创建对象。因为它持有一堆对象，所以又叫容器

和简单工厂区别

• 简单工厂负责一类（eg不同文本类型）对象的创建。一般要创建哪些对象，都是代码提前写死的new好
• DI容器负责的是整个应用程序所有对象的创建。除此之外，它还要负责对象生命周期的管理。DI事先不知道要创建哪些对象，是根据解析配置来动态创建对象

手动实现一个DI容器

使用

• Demo

public class Demo {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext("beans.xml");
        
        RateLimiter rateLimiter = (RateLimiter) applicationContext.getBean("rateLimit");
        
        rateLimiter.func();
    }
}
1
2
3
4
5
6
7
8
9

• 接口

public interface ApplicationContext {
    Object getBean(String beanId);
}
1
2
3

• 实现类

public class ClassPathXmlApplicationContext implements ApplicationContext {
    private BeanConfigParser beanConfigParser;
    private BeansFactory beansFactory;

    public ClassPathXmlApplicationContext(String configLocation) {
        this.beansFactory = new BeansFactory();
        this.beanConfigParser = new XmlBeanConfigParser();
        loadBeanDefinitions(configLocation);
    }

    // 解析器，读取xml配置为BD，并将BD放入beanFactory
    private void loadBeanDefinitions(String configLocation) {
        InputStream in = this.getClass().getResourceAsStream("/" + configLocation);
        List<BeanDefinition> beanDefinitions = beanConfigParser.parse(in);
        beansFactory.addBeanDefinitions(beanDefinitions);
    }

    // 从beanFactory创建bean
    @Override
    public Object getBean(String beanId) {
        return beansFactory.getBean(beanId);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

• DeanDefination

@Data
public class BeanDefinition {
    private String id;
    private String className;
    private List<ConstructorArg> constructorArgs = new ArrayList<>();
    private Scope scope = Scope.SINGLETON;//单例
    private boolean lazyInit = false;//懒加载false

    public boolean isSingleton() {
        return scope.equals(Scope.SINGLETON);
    }

    public static enum Scope {
        SINGLETON,
        PROTOTYPE
    }
    
    @Data
    public static class ConstructorArg {
        private boolean isRef;//bean中是否有对象依赖
        private Class type;//对象依赖类型
        private Object arg;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

1、配置解析

• xml配置文件

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="rateLimiter" class="com.xxx.lean.RateLimiter">
        <constructor-arg ref="redis">constructor-arg>
    bean>

    <bean id="redis" class="com.mjp.lean.Redis">
        <constructor-arg type="java.lang.String" value="127.0.0.1"/>
        <constructor-arg type="int" value="6001"/>
    bean>
beans>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

• 配置类

@NoArgsConstructor
@AllArgsConstructor
@Data
public class RateLimiter {
    private Redis redis;
}

@AllArgsConstructor
@NoArgsConstructor
@Data
public class Redis {
    private String ipAddress;
    private int port;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 解析配置类并生成BeanDefination放入BeanFactory

主要就是将is解析成BD

public interface BeanConfigParser {
    List<BeanDefinition> parse(InputStream inputStream);

}

public class XmlBeanConfigParser implements BeanConfigParser {
    @Override
    public List<BeanDefinition> parse(InputStream inputStream) {
        String content = null;
        return parse(content);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

2、BeanFactory通过反射创建对象

public class BeansFactory {
    private ConcurrentHashMap<String, Object> singletonObjects = new ConcurrentHashMap<>();
    private ConcurrentHashMap<String, BeanDefinition> beanDefinitions = new ConcurrentHashMap<>();

    // 存储BD
    public void addBeanDefinitions(List<BeanDefinition> beanDefinitionList) {
        for (BeanDefinition beanDefinition : beanDefinitionList) {
            this.beanDefinitions.putIfAbsent(beanDefinition.getId(), beanDefinition);
        }
        for (BeanDefinition beanDefinition : beanDefinitionList) {
            if (beanDefinition.isLazyInit() == false && beanDefinition.isSingleton())
                createBean(beanDefinition);
        }
    }

    // 获取bean
    public Object getBean(String beanId) {
        BeanDefinition beanDefinition = beanDefinitions.get(beanId);
        return createBean(beanDefinition);
    }

    // 反射创建bean
    protected Object createBean(BeanDefinition beanDefinition) {
        // 单例则直接从池中拿取对象并返回
        if (beanDefinition.isSingleton() && singletonObjects.contains(beanDefinition)) {
            return singletonObjects.get(beanDefinition.getId());
        }

        Object bean = null;
        try {
            Class beanClass = Class.forName(beanDefinition.getClassName());
            List<BeanDefinition.ConstructorArg> args = beanDefinition.getConstructorArgs();

            // 如果此bean没有依赖的bean，则直接创建对象即可
            if (args.isEmpty()) {
                bean = beanClass.newInstance();
            } else {
                // 否则，需要按个创建依赖的BD对象的bean
                Class[] argClasses = new Class[args.size()];
                Object[] argObjects = new Object[args.size()];
                for (int i = 0; i < args.size(); ++i) {
                    BeanDefinition.ConstructorArg arg = args.get(i);
                    if (arg.isRef()) {
                        // 当此bean对象的构造函数中参数是ref类型时，则递归创建ref属性指向的对象
                        BeanDefinition refBeanDefinition = beanDefinitions.get(arg.getArg());
                        argClasses[i] = Class.forName(refBeanDefinition.getClassName());//依赖BD的ref类型（User.class）
                        argObjects[i] = createBean(refBeanDefinition);//依赖BD的具体值User("mjp",18)
                    } else {
                        argClasses[i] = arg.getType();
                        argObjects[i] = arg.getArg();
                    }
                }
                // 通过反射获取有参构造器，然后再通过newInstance传递构造器入参值，创建对象
                bean = beanClass.getConstructor(argClasses).newInstance(argObjects);
            }
        } catch (Exception e) {
        }

        // 如果对象时单例的，则需要放入缓存池中
        if (bean != null && beanDefinition.isSingleton()) {
            singletonObjects.putIfAbsent(beanDefinition.getId(), bean);
            return singletonObjects.get(beanDefinition.getId());
        }
        return bean;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

3、对象生命周期管理

• 单例
• 懒加载：lazy-init = false。所有对象在应用启动的时候就创建好
• init-method 和 destroy-method

比如 initmethod=loadProperties(),在创建好对象后，会主动调用 init-method属性指定的方法来初始化对象。

destroy-method=updateConfigFile(),在对象被最终销毁之前,会主动调用 destroy-method 属性指定的方法来做一些清理工作(释放数据库连接池、关闭文件)。

3.1.4 Builder建造者模式

和set以及构造器的区别

1、构造器的缺点

如果类中有很多的属性，则new X（太多的属性，容易赋值错）

2、set方法的缺点

• 即使对象被final修饰，也是对象指向的地址是不可变的，但是堆地址的内容还是可以通过set赋值可变。

当要求对象一旦被new其属性值就不允许被修改，则不能对外暴露set

• set方法也无法校验传递参数是否正确，更无法校验多个属性之间的关系(eg:最大线程数 必须 > 核心线程数)

3、建造者的缺点：

建造者内部类中也需要再定义一遍和外部类中一样的属性

建造者模式创建对象

1、private 构造器

2、只提供get方法，不提供set

3、定义成员内部类Builder类

• 单个setXxx中可以校验某个属性
• 最终build方法new 对象之前，可以校验各个属性之间的关系

@Getter
@ToString
public class ThreadConfig {
    private String name;
    private Integer coreCount;
    private Integer maxCount;
    
    private ThreadConfig(ThreadConfigBuilder threadConfigBuilder) {
        this.name = threadConfigBuilder.name;
        this.coreCount = threadConfigBuilder.coreCount;
        this.maxCount = threadConfigBuilder.maxCount;
    }

    @ToString
    private class ThreadConfigBuilder {
        public String name;
        public Integer coreCount;
        public Integer maxCount;
        
        public ThreadConfigBuilder setName(String name) {
            if (StringUtils.isBlank(name)) {
                throw new IllegalArgumentException("线程池名称不能为空");
            }
            this.name = name;
            return this;
        }

        public ThreadConfigBuilder setCoreCount(Integer coreCount) {
            if (coreCount == null || coreCount <= 0) {
                throw new IllegalArgumentException("线程池核心线程数必须为正整数");
            }
            this.coreCount = coreCount;
            return this;
        }

        public ThreadConfigBuilder setMaxCount(Integer maxCount) {
            if (maxCount == null || maxCount <= 0) {
                throw new IllegalArgumentException("线程池最大线程数必须为正整数");
            }
            this.maxCount = maxCount;
            return this;
        }
        
        public ThreadConfig build() {
            if (coreCount > maxCount) {
                throw new IllegalArgumentException("线程池最大线程数必须大于核心线程数");
            }
            return new ThreadConfig(this);
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

实战@Accessors

@Data
@Accessors(chain = true)
public class UserDemo {
    private String name;
    private Integer age;
}

UserDemo m = new UserDemo().setName("m").setAge(18);
1
2
3
4
5
6
7
8

和工厂模式的区别

工厂模式是创建一系列相同类型的对象

建造者模式是创建一个复杂属性的对象

3.2结构型：类或对象的组合

代理、装饰者、适配器、享元

3.2.1Proxy代理模式

定义

在不改变原有类的情况下，引入代理类来给原始类附加功能

场景

日志打印、权限校验、限流、事务、最大努力重试

动态代理接口实现

为给个接口方法的执行，计算花费的时间

public class StopWatchProxy {
    public Object creatProxy(Object target) {
        Class<?> aClass = target.getClass();
        ClassLoader classLoader = aClass.getClassLoader();
        Class<?>[] interfaces = aClass.getInterfaces();
        return Proxy.newProxyInstance(classLoader, interfaces, (proxy, method, args) -> {
            long start = System.currentTimeMillis();
            Object result = method.invoke(target, args);
            long end = System.currentTimeMillis();
            System.out.println((end - start));
            return result;
        });
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

public interface User {
    void eat();
}

public class UserImpl implements User{
    @Override
    public void eat() {
        System.out.println("eat");
    }
}
1
2
3
4
5
6
7
8
9
10

StopWatchProxy stopWatchProxy = new StopWatchProxy();
User user = (User) stopWatchProxy.creatProxy(new UserImpl());
user.eat();
1
2
3

3.2.2 装饰器模式

作用

给原始类添加增强功能

和代理模式的区别

代理模式中代理类附加的是跟原始类无关的功能（日志、权限校验等）；装饰器类附加的是跟原始类相关的增强功能（原始类是直接读、装饰类增加的功能是缓存读）

实现

• 装饰器类（ADeractor）需要跟原始类（A）继承相同的抽象类（AbstractA） | 接口（IA）。
• 装饰器类（ADeractor）中组合原始类（A）

可以对A嵌套使用多个装饰器类

• 接口|抽象类

public interface IA {
    void f();
}
1
2
3

• 原始类

@Service
public class A implements IA{
    @Override
    public void f() {
        System.out.println("f");
    }
}
1
2
3
4
5
6
7

• 装饰类

@Service
public class ADecorator implements IA{
    @Resource
    private A a;

    @Override
    public void f() {
        // 增强
        System.out.println("增强1");
        a.f();
        // 增强
        System.out.println("增强2");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 使用

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ApplicationLoader.class)
public class SpringTest {
    @Resource
    private ADecorator aDecorator;

    @Test
    public void test() {
        aDecorator.f();
    }
}
1
2
3
4
5
6
7
8
9
10
11

场景IO流

1、结构

• 字节流-读InpuStream
  • FileInputStream
  • ByteArrayInputStream
  • FilterInputStream
    • BufferedInputStream
    • DateInputStream
• 字符流-读Reader
  • BufferedReader
  • InputStreamReader
    • FileReader

2、源码结构

抽象类：InputStream

A：FileInputStream

ADecorator：BufferedInputStream、DateInputStream

FileInputStream fis = new FileInputStream(new File("xxx.txt"));
BufferedInputStream bis = new BufferedInputStream(fis);
bis.read();
1
2
3

3、前置背景

3.1 使用装饰者增强后的read

    @Test
    public void test() throws IOException {
        FileInputStream fis = new FileInputStream(new File(""));
        SonBufferedInputStream bis = new SonBufferedInputStream(fis);
        bis.read();
    }
1
2
3
4
5
6

3.3 抽象-read

public abstract class InputStream implements Closeable {
    public abstract int read() throws IOException;
}
1
2
3

3.3 A-read

public class FileInputStream extends InputStream{
    public int read() throws IOException {
        return read0();
    }  
    private native int read0() throws IOException;
}
1
2
3
4
5
6

3.4 ADecorator -read

public class SonBufferedInputStream extends FatherFilterInputStream {
    public SonBufferedInputStream(FileInputStream fis) {
        super(fis);
    }

    public int read() throws IOException {
        // A的read
        fis.read(null, 1, 1);
        // 增强
        return 1;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

• 虽然ADecorator（SonBufferedInputStream）中没有直接定义属性A（FileInputStrteam），但是其父类中定义了

@Data
@AllArgsConstructor
public class FatherFilterInputStream extends InputStream {
    protected FileInputStream fis;

    @Override
    public int read() throws IOException {
        return fis.read();
    }
}
1
2
3
4
5
6
7
8
9
10

这样当执行SonBufferedInputStream bis = new SonBufferedInputStream(fis)时

• super(fis)
• 即将A（FileInputStrteam）赋值给了其父类属性A a，这样等效子类ADecorator也具有了A a属性值
• 所以，当执行bis.read()时，一方面执行了a.read，另一方面执行了增强方法。实现了装饰功能

4、源码解析

4.1 抽象类InputStream-read()

4.2 A : read（是个nativate方法）

public class FileInputStream extends InputStream{
	private native int read() throws IOException;
}
1
2
3

4.3 ADecorator（BufferedInputStream）-read

这里的BufferedInputStream bis = new BufferedInputStream(fis);
=》
    public BufferedInputStream(InputStream in, int size) {
        super(in);//super(fis)
        buf = new byte[size];
    }
=>
public class FilterInputStream extends InputStream {
    //即ADecorator中组合了A（fis）
    protected volatile InputStream in;//fis
    protected FilterInputStream(InputStream in) {
        this.in = in;//this.fis = fis
    }   
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

==》等效

public class FilterInputStream extends InputStream {
    protected volatile FileInputStream fis;
    protected FilterInputStream(FisleInputStream fis) {
        this.fis = fis;
    }   
}
1
2
3
4
5
6

这样一来，就相当于子类ADecorator（Buffered）中通过继承父类也具有属性A（FileInputStream）

4.4 bis.read()

public synchronized int read() throws IOException {
	fill();//实现
	return getBufIfOpen()[pos++] & 0xff;
}
1
2
3
4

private void fill() throws IOException {
    // 增强功能缓存
    byte[] buffer = getBufIfOpen();
    // 调用属性a 的方法
    int n = getInIfOpen().read(buffer, pos, buffer.length - pos);
}
1
2
3
4
5
6

private InputStream getInIfOpen() throws IOException {
   InputStream input = in;//fis
   return input;
}
1
2
3
4

getInIfOpen().read(buffer, pos, buffer.length - pos) ==相当于使用fis.read(buffer, pos, buffer.length - pos)

public class FileInputStream{
	public int read(byte b[], int off, int len) throws IOException {
        return readBytes(b, off, len);
    }
    
    private native int readBytes(byte b[], int off, int len) throws IOException;
}
1
2
3
4
5
6
7

这样一来，ADcorator中使用了buffer增强了fis的read

4.5 父类作用

完全可以直接将属性A a放入ADecorator中

public class BufferedInputStream extends InputStream {
    private FileInputStream fis;
    public int read(){
       //
    }
}
1
2
3
4
5
6

为什么采用，将A a 放入父类中，然后子类继承父类属性的方式从而子类ADecorator也具有了属性A。

父类作用：

• 让自子类Buffered、Data只需要关注A（Fis）中需要增强的方法，比如A中的read方法的Buffered为其增强为具有缓存功能的字节流读。

• A类的其它不需要增强的方法都交给父类FilterInputStream的去关注去实现，这样众多装饰者子类就无需重写

3.2.3 适配器模式

定义

将不兼容的接口转为可兼容的接口，让原本因为接口不兼容无法在一起工作的类可以一起工作

实现

1、类适配器-继承

• 需要配适配的

public class Adaptee {
    public void query() {
        System.out.println("query");
    }
    
    public void add() {
        System.out.println("add");
    }
    
    public void delete() {
        System.out.println("delete");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

• 适配成什么样子，即目标

  除了add方法还是使用Adaptee的，查询和删除都使用适配后的新方法

public interface Target {
    void queryNew();
    void add();
    void deleteNew();
}
1
2
3
4
5

• 适配器

@Service
public class Adapter extends Adaptee implements Target{
    @Override
    public void queryNew() {
        super.query();
    }

    @Override
    public void deleteNew() {
        if (true) {
            // 执行新的删除逻辑
            System.out.println("delete new");
        } else {
            super.delete();
        }
    }
    
    // 这里类适配器最大的特点就是：
    理论上需要重写add方法，但是由于继承了父类的add，所以可以不用重写add
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

• 使用

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ApplicationLoader.class)
@Slf4j
public class SpringTest {
    @Resource
    private Target target;

    @Test
    public void test() throws IOException {
        target.queryNew();
        target.add();
        target.deleteNew();
    }
}
query
add
delete new
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

• 使用场景

目标Target和原Adaptee中大部分方法都一样，没有那么多方法需要适配的时候，使用类继承，这样很多方法（比如像add）都无需重写。

2、对象适配器-组合

• 适配器

@Service
public class AdapterObj implements Target{
    @Resource
    private Adaptee adaptee;

    @Override
    public void queryNew() {
        adaptee.query();
        // 再---
    }

    @Override
    public void add() {
        adaptee.add();
    }

    @Override
    public void deleteNew() {
        if (true) {
            System.out.println("delete new");
        } else {
            adaptee.delete();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

• 使用场景

目标Target和原Adaptee中大部分方法都不一样即定义不同

场景

1、兼容老接口

• 背景

原本查询黑名单接口BlackListService#queryBlackList(Long poiId)根据仓id查询仓下的所有很名单。

本次需求查询黑名单时，除了需要仓id外，还需要businessType

• 实现方式1

  直接修改BlackListService#queryBlackList(Long poiId，Integer businessType)方法声明和逻辑

  • 优点：无需重构

  • 缺点：风险大，线上很多业务使用到这个方法，一旦方法有问题相当于全量了，风险不可控

• 实现方式2：适配器模式

  @Service
  public class BlackListAdaptee {
      public List<Object> queryBlackList(Long poiId){
          return Lists.newArrayList();
      }
  }
  1
  2
  3
  4
  5
  6

  public interface BlackListServiceTarget {
      List<Object> queryBlackListNew(Long poiId, Integer businessType);
  }
  1
  2
  3

  @Service
  public class BlackListServiceAdaptor extends BlackListAdaptee implements BlackListServiceTarget{
      @Override
      public List<Object> queryBlackListNew(Long poiId, Integer businessType) {
          if (true) {//命中了灰度仓
              System.out.println("根据poi和businessType查询黑名单");
              return Lists.newArrayList();
          } else {
              // 非灰度仓走老逻辑查询，查询结果按照businessType进行过滤即可
              List<Object> blackList = super.queryBlackList(poiId);
              return blackList.stream().filter(Objects::nonNull).collect(Collectors.toList());
          }
  
      }
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15

  @RunWith(SpringRunner.class)
  @SpringBootTest(classes = ApplicationLoader.class)
  @Slf4j
  public class SpringTest {
      @Resource
      private BlackListServiceAdaptor blackListServiceAdaptor;
      
      @Resource
      private BlackListServiceAdaptee blackListServiceAdaptee;
  
      @Test
      public void test() throws IOException {
          // 原本的业务逻辑
          //List