常用设计模式

最新推荐文章于 2024-05-30 16:03:07 发布

yq15797688367

最新推荐文章于 2024-05-30 16:03:07 发布

阅读量806

点赞数 9

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/yq15797688367/article/details/137629035

版权

设计模式专栏收录该内容

1 篇文章 0 订阅

订阅专栏

代码好坏评估

可维护性：可以在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码，解决bug，
可读性：代码容易理解，不会存在很多疑问。可以从是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等方面评估。
可扩展性：在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。
可复用性：尽量减少重复代码的编写，复用已有的代码。继承和多态就是体现了可复用性。
重复不一定是代码一样，也不一定代码不一样就不算重复。比如实现逻辑重复（代码执行过程一样）但实现功能不重复时不算重复，实现逻辑不重复但功能重复时算重复。

设计原则是根，设计模式是为了在设计原则的基础上达到可维护性、可读性和可扩展性的效果。

设计原则

单一职责原则

一个类（模块）负责一个功能（职责）（可以是多个相同功能的类组合成模块完成一个功能）。
类功能单一，粒度小，当一个类中包含多个不相干的业务时，即可将该类进行拆分成多个功能单一、粒度更小的类。多个功能相同的方法放在同一个类中

如何判断类的职责是否足够单一？
不同的应用场景、不同阶段的需求背景、不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。
出现下面这些情况就有可能说明这类的设计不满足单一职责原则：

类中的代码行数、函数或者属性过多；
类依赖的其他类过多，或者依赖类的其他类过多；
私有方法过多；
比较难给类起一个合适的名字；
类中大量的方法都是集中操作类中的某几个属性。

在实际开发时可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，就可以将这个粗粒度的类，拆分成几个更细粒度的类，完成代码重构。

类的职责是否设计得越单一越好
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性，要根据实际情况来决定细化程度。

开闭原则

软件实体（类、模块、方法）对扩展开放，对修改关闭
在已有代码上进行扩展（增加新的类、模块方法），而不是在已有代码上进行修改（类、模块、方法）

并不是做了修改就不符合开闭原则，开闭原则可以应用在不同粒度的代码中，可以是
模块，也可以类，还可以是方法（及其属性）。同样一个代码改动，在粗代码粒度下，被认
定为“修改”，在细代码粒度下，又可以被认定为“扩展”。只要代码改动的时候没有破坏原有的代码的正常运行，没有破坏原有的单元测试，以最小的代价完成扩展，就OK，只是在修改的时候保持代码可维护性、可读性以及可扩展。

如何运用开闭原则
开闭原则就是扩展性，因此在写代码时需要具有扩展意识、抽象意识、封装意识，要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点（可能会增加的需求），以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。
识别出代码可变部分和不可变部分之后，将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。就好比策略模式，使用这个服务时，可能有其他可替换的服务使用，那么就要将这些服务抽取出一个上层的类或者借口来实现扩展。

里式替换原则

父类出现的地方都可以使用子类进行替换，且保证代码的逻辑行为没有变化（类似于多态，但是替换时前后调用方法中的运行逻辑要是一样，比如父类中方法没有异常情况，子类中那么该增强的方法也不应该出现异常情况）。

子类在设计的时候，要遵守父类的行为约定（或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。实际上，定义中父类和子类之间的关系，也可以替换成接口和实现类之间的关系。（也就是父类是怎么实现的子类就要怎么实现，只是可以做一点增强）

接口隔离原则

接口可以分为三种理解：

一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。
单个 API 接口或函数，部分调用者只需要函数中的部分功能，需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数（单个函数中不要有多种方式通过if来分开，直接分为多个函数）。
OOP 中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数（接口提供的功能要单一）。

接口隔离原则与单一职责原则的区别
单一职责原则针对的是模块、类、接口的设计，针对的是某个业务功能。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

依赖反转原则

高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。高低层模块根据调用链来区分，调用者为高层模块。

迪米特原则

高内聚：高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。
低耦合：类与类之间的依赖关系简单清晰，即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。

创建型模式

单例模式 *

单例模式及每个类只允许有一个实例对象存在。
作用：

解决资源访问时可能存在的冲突：比如程序中日志都是写入同一个文件，当存在多个现成写日志时，为了避免相互覆盖，需要实现互斥，这时候就可以将写日志以及锁封装成一个单例对象。（需要实现互斥时使用单例）
全局唯一对象：当程序中某个对象只允许存在一个时，则设置成单例对象，比如ID号码生成器、配置信息类等。

因素：

构造函数为 private 访问权限，这样才能避免外部通过 new 创建实例，实例属性私有；
考虑对象创建时的线程安全问题；
考虑是否支持延迟加载；
考虑 getInstance() 性能是否高（是否加锁）。

饿汉式

在类加载的时候，instance 静态实例就已经创建并初始化好了，所以，instance 实例的创建过程是线程安全的，不支持延迟加载。（static final方式实现）

import java.util.concurrent.atomic.AtomicLong;

public class IdGenerator {
    private AtomicLong id = new AtomicLong(0);
    private static final IdGenerator instance = new IdGenerator();  // 类加载的时候创建对象，线程安全

    private IdGenerator() {
    }

    public static IdGenerator getInstance() {
        return instance;
    }

    public long getId() {
        return id.incrementAndGet();
    }
}

懒汉式

在第一次使用的时候创建，支持延迟加载

import java.util.concurrent.atomic.AtomicLong;

public class IdGenerator {
    private AtomicLong id = new AtomicLong(0);
    private static IdGenerator instance;

    private IdGenerator() {
    }

    public static synchronized IdGenerator getInstance() {  // static静态方法实现线程安全，避免创建多个单例对象
        if (instance == null) {  // 在方法上面加synchronized锁，每次访问的时候都会加锁释放锁，并发度低，性能低
            instance = new IdGenerator();
        }
        return instance;
    }

    public long getId() {
        return id.incrementAndGet();
    }
}

双端检测

支持延迟加载（非final实例），性能比懒汉式高（不存在创建对象在加锁）

import java.util.concurrent.atomic.AtomicLong;

public class IdGenerator {
    private AtomicLong id = new AtomicLong(0);
    private static volatile IdGenerator instance;

    private IdGenerator() {
    }

    public static synchronized IdGenerator getInstance() {
        if (instance == null) {
            synchronized (IdGenerator.class){
                if(instance == null){  // 双端检测，避免多个对象同时进入时多次创建对象
                    instance = new IdGenerator();  // 避免创建对象、初始化、赋值出现指令重排序，还没有赋值就已经投入使用，因此需要使用volatile关键字
                }
            }

        }
        return instance;
    }

    public long getId() {
        return id.incrementAndGet();
    }
}

静态内部类

比双重检测简单的实现方式

import java.util.concurrent.atomic.AtomicLong;

public class IdGenerator {
    private AtomicLong id = new AtomicLong(0);

    private static class SingletonHolder { // 第一次访问的时候才会加载该类从而实例化，通过jvm实现线程安全
        private static final IdGenerator instance = new IdGenerator();
    }

    private IdGenerator() {
    }

    public static synchronized IdGenerator getInstance() {
        return SingletonHolder.instance;
    }

    public long getId() {
        return id.incrementAndGet();
    }
}

枚举

通过 Java 枚举类型本身的特性，保证了实例创建的线程安全性和实例的唯一性

public enum IdGenerator {
    INSTANCE;
    private AtomicLong id = new AtomicLong(0);

    public long getId() {
        return id.incrementAndGet();
    }
}

工厂模式*

简单工厂

/**
 * 大部分工厂类都是以“Factory”这个单词结尾的，但也不是必须的，比如 Java 中的DateFormat、Calender。
 * 除此之外，工厂类中创建对象的方法一般都是 create 开头，比如代码中的 createParser()，
 * 但有的也命名为 getInstance()、createInstance()、newInstance()，有的甚至命名为 valueOf()（比如 Java String 类的 valueOf() 函数）等
 */
public class RuleConfigParserFactory {  
    public static IRuleConfigParser createParser(String configFormat) {
        IRuleConfigParser parser = null;
        if ("json".equalsIgnoreCase(configFormat)) {
            parser = new JsonRuleConfigParser();   // 多个if来实现同一功能不同实现方式的对象的创建
        } else if ("xml".equalsIgnoreCase(configFormat)) {
            parser = new XmlRuleConfigParser();
        } else if ("yaml".equalsIgnoreCase(configFormat)) {
            parser = new YamlRuleConfigParser();
        } else if ("properties".equalsIgnoreCase(configFormat)) {
            parser = new PropertiesRuleConfigParser();
        }
        return parser;
    }
}

改进版，重复利用已经创建好的对象。单例模式和简单方法结合

public class RuleConfigParserFactory {
    private static final Map<String, RuleConfigParser> cachedParsers = new HashMaP<>();
    // 单例模式和简单工厂方法结合，提高对象的复用性，避免多次创建相同功能的对象
    static {
        cachedParsers.put("json", new JsonRuleConfigParser());
        cachedParsers.put("xml", new XmlRuleConfigParser());
        cachedParsers.put("yaml", new YamlRuleConfigParser());
        cachedParsers.put("properties", new PropertiesRuleConfigParser());
    }

    public static IRuleConfigParser createParser(String configFormat) {
        if (configFormat == null || configFormat.isEmpty()) {
            return null;//返回null还是IllegalArgumentException按照情况来决定
        }
        IRuleConfigParser parser = cachedParsers.get(configFormat.toLowerCase());
        return parser;
    }
}

工厂方法

将对象的创建封装成一个个的工厂类，然后增加的时候只需要继承然后新增类即可，比简单方法更符合开闭原则

public interface IRuleConfigParserFactory {
    IRuleConfigParser createParser();
}

public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
        return new JsonRuleConfigParser();
    }
}

public class XmlRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
        return new XmlRuleConfigParser();
    }
}

public class YamlRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
        return new YamlRuleConfigParser();
    }
}

public class PropertiesRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
        return new PropertiesRuleConfigParser();
    }
}

这些工厂类使用简单方法进行封装

public class RuleConfigParserFactoryMap { //工厂的工厂
    private static final Map<String, IRuleConfigParserFactory> cachedFactories =

    static {
        cachedFactories.put("json", new JsonRuleConfigParserFactory());
        cachedFactories.put("xml", new XmlRuleConfigParserFactory());
        cachedFactories.put("yaml", new YamlRuleConfigParserFactory());
        cachedFactories.put("properties", new PropertiesRuleConfigParserFactory())
    }

    public static IRuleConfigParserFactory getParserFactory(String type) {
        if (type == null || type.isEmpty()) {
            return null;
        }
        IRuleConfigParserFactory parserFactory = cachedFactories.get(type.toLowerCa
        return parserFactory;
    }
}

工厂方法和简单工厂怎么选
当创建对象只是简单的new一下时，那么选择简单工厂
如果还需要额外的操作，比如组合其他类对象，做各种初始化操作的时候，则选择工厂方法

抽象工厂

建造者模式*

创建对象时，所有的属性设置都可以通过new构造函数赋值。当可配置项逐渐增多，为 8 个、10 个，甚至更多，构造函数的参数列表会变得很长，同时由于对每个属性都要进行检验在赋值，代码在可读性和易用性上都会变差。在使用构造函数的时候，我们就容易搞错各参数的顺序，传递进错误的参数值，导致非常隐蔽的 bug。
可以在new构造核心属性后通过set方法设置来优化对象创建，从而减少构造函数中参数长以及代码多的问题。但是当核心属性比较多时还是有同样的问题。同时当对象对不可变对象时，属性初始化后不可进行值修改，那么就不可以暴露set方法。
此外，当属性之间存在依赖关系时，比如当赋值了其中一个值就必须显示给其他属性赋值，或者某个属性值要小于另外一个属性等关系时，set方法无法完成。

由上述问题时，则可以使用建造者模式来解决。

public class ResourcePoolConfig {
    private String name;
    private int maxTotal;
    private int maxIdle;
    private int minIdle;

    private ResourcePoolConfig(Builder builder) {
        this.name = builder.name;
        this.maxTotal = builder.maxTotal;
        this.maxIdle = builder.maxIdle;
        this.minIdle = builder.minIdle;
    }
    //...省略getter方法...

    //我们将Builder类设计成了ResourcePoolConfig的内部类。
    //我们也可以将Builder类设计成独立的非内部类ResourcePoolConfigBuilder。
    public static class Builder {
        private static final int DEFAULT_MAX_TOTAL = 8;
        private static final int DEFAULT_MAX_IDLE = 8;
        private static final int DEFAULT_MIN_IDLE = 0;

        private String name;
        private int maxTotal = DEFAULT_MAX_TOTAL;
        private int maxIdle = DEFAULT_MAX_IDLE;
        private int minIdle = DEFAULT_MIN_IDLE;

        public ResourcePoolConfig build() {
            // 校验逻辑放到这里来做，包括必填项校验、依赖关系校验、约束条件校验等
            if (StringUtils.isBlank(name)) {
                throw new IllegalArgumentException("...");
            }
            if (maxIdle > maxTotal) {
                throw new IllegalArgumentException("...");
            }
            if (minIdle > maxTotal || minIdle > maxIdle) {
                throw new IllegalArgumentException("...");
            }

            return new ResourcePoolConfig(this);
        }

        public Builder setName(String name) {
            if (StringUtils.isBlank(name)) {
                throw new IllegalArgumentException("...");
            }
            this.name = name;
            return this;
        }

        public Builder setMaxTotal(int maxTotal) {
            if (maxTotal <= 0) {
                throw new IllegalArgumentException("...");
            }
            this.maxTotal = maxTotal;
            return this;
        }

        public Builder setMaxIdle(int maxIdle) {
            if (maxIdle < 0) {
                throw new IllegalArgumentException("...");
            }
            this.maxIdle = maxIdle;
            return this;
        }

        public Builder setMinIdle(int minIdle) {
            if (minIdle < 0) {
                throw new IllegalArgumentException("...");
            }
            this.minIdle = minIdle;
            return this;
        }
    }
}

// 这段代码会抛出IllegalArgumentException，因为minIdle>maxIdle
ResourcePoolConfig config = new ResourcePoolConfig.Builder()
        .setName("dbconnectionpool")
        .setMaxTotal(16)
        .setMaxIdle(10)
        .setMinIdle(12)
        .build();

原型模式

如果对象的创建成本比较大，而同一个类的不同对象之间差别不大（大部分字段都相同），在这种情况下，可以利用对已有对象（原型）进行**复制（或者叫拷贝）**的方式来创建新对象，以达到节省创建时间的目的。这种基于原型来创建对象的方式就叫作原型模式。

那何为“对象的创建成本比较大”
实际上，创建对象包含的申请内存、给成员变量赋值这一过程，本身并不会花费太多时间，或者说对于大部分业务系统来说，这点时间完全是可以忽略的。应用一个复杂的模式，只得到一点点的性能提升，这就是所谓的过度设计，得不偿失。
但是，如果对象中的数据需要经过复杂的计算才能得到（比如排序、计算哈希值），或者需要从 RPC、网络、数据库、文件系统等非常慢速的 IO 中读取，这种情况下，我们就可以利用原型模式，从其他已有对象中直接拷贝得到，而不用每次在创建新对象的时候，都重复执行这些耗时的操作。

结构型模式

结构型模式描述了类与类之间的组合结构

代理模式*

在不改变被代理类代码的基础上，对被代理类中的方法进行功能增强，或者添加新的功能。

当被代理类实现了某个接口，代理的时候代理类和被代理类需要实现同一个接口。

当被代理类为第三方库的类，或者没有实现接口，则需要通过继承的方式实现代码增强。

应用场景：

业务系统的非功能性需求开发：将业务系统中的监控、统计、鉴权、限流、事务、幂等、日志等通用功能抽取出来，与业务代码进行解耦，放到代理类中统一处理。Spring AOP也是代理模式

桥接模式

将抽象和实现解耦，让它们能独立开发。类似于SPI开发。

装饰者模式*

利用组合的方式对现有类进行功能增强。

比如IO流中的各种装饰类，下图为java中IO各种类，其中不同的基础输入对象流FileInputStream（文件）、byteArrayInputStream（字节数组）、ObjectInputStream(对象)等。
不同的封装装饰器流，BufferedInputStream，基础输入流的功能上添加了一个缓冲区、写入输入流之前数据都保存在缓冲区中，缓冲满了都时候在一次性写入文件中，减少了IO次数，DataInputStream自动读取目标数据类型的字节数并转换。
基于组合的方式，每个装饰类可以对不同的类进行增强，而继承需要对每个被装饰类都要新增一个子类。
在这里插入图片描述
装饰器模式和代理模式的结构比较类似，但是这两种针对的目标不同，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。

适配器模式*

将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作，就好比手机里的转接头。
适配器模式有两种实现方式：类适配器和对象适配器。其中，类适配器使用继承关系来实现，对象适配器使用组合关系来实现。

public interface ITarget {
    void f1();

    void f2();

    void fc();
}
// 需要适配的类，根据需要被适配的API创建接口ITarget
public class Adaptee {
    public void fa() {
        //... 
    }

    public void fb() { //...
    }

    public void fc() { //... 
    }
}
// 类适配器，基于继承
// 继承被适配类，并实现适配接口
public class Adaptor extends Adaptee implements ITarget {
    public void f1() {  // 需要适配的API进行封装
        super.fa();
    }

    public void f2() {
        //...重新实现f2()...
    }

    // 这里fc()不需要实现，直接继承自Adaptee，这是跟对象适配器最大的不同点
}

// 对象适配器：基于组合
public class Adaptor implements ITarget {
    private Adaptee adaptee;

    public Adaptor(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    public void f1() {
        adaptee.fa(); //委托给Adaptee
    }

    public void f2() {
        //...重新实现f2()...
    }

    public void fc() {
        adaptee.fc();
    }
}
//如果 Adaptee 接口并不多，那两种实现方式都可以。
//如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都相同，则使用类适配器，
//因为 Adaptor 复用父类 Adaptee 的接口，比起对象适配器的实现方 式，Adaptor 的代码量要少一些。
//如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都不相同，则使用对象适配器，因为组合结构相对于继承更加灵活。

使用场景：

外部API设计不规范，比如参数过多等，因为外部API三方提供，没有权限修改，则可使用适配器模式进行二次封装。
统一多个类的接口设计，当同时需要多个类提供的功能类似但方法名不同时，将多个方法抽取出来设计一个接口来对功能API进行统一，并通过适配器模式对每个类进行适配。

public class ASensitiveWordsFilter { // A敏感词过滤系统提供的接口
    //text是原始文本，函数输出用***替换敏感词之后的文本
    public String filterSexyWords(String text) {
        // ...
    }

    public String filterPoliticalWords(String text) {
        // ...
    }
}

public class BSensitiveWordsFilter { // B敏感词过滤系统提供的接口
    public String filter(String text) {
        //...
    }
}

public class CSensitiveWordsFilter { // C敏感词过滤系统提供的接口
    public String filter(String text, String mask) {
        //...
    }
}

// 未使用适配器模式之前的代码：代码的可测试性、扩展性不好
public class RiskManagement {
    private ASensitiveWordsFilter aFilter = new ASensitiveWordsFilter();
    private BSensitiveWordsFilter bFilter = new BSensitiveWordsFilter();
    private CSensitiveWordsFilter cFilter = new CSensitiveWordsFilter();

    public String filterSensitiveWords(String text) {
        String maskedText = aFilter.filterSexyWords(text);
        maskedText = aFilter.filterPoliticalWords(maskedText);
        maskedText = bFilter.filter(maskedText);
        maskedText = cFilter.filter(maskedText, "***");
        return maskedText;
    }
}

// 使用适配器模式进行改造
public interface ISensitiveWordsFilter { // 统一接口定义
    String filter(String text);
}

public class ASensitiveWordsFilterAdaptor implements ISensitiveWordsFilter {
    private ASensitiveWordsFilter aFilter;

    public String filter(String text) {
        String maskedText = aFilter.filterSexyWords(text);
        maskedText = aFilter.filterPoliticalWords(maskedText);
        return maskedText;
    }
}
//...省略BSensitiveWordsFilterAdaptor、CSensitiveWordsFilterAdaptor...

// 扩展性更好，更加符合开闭原则，如果添加一个新的敏感词过滤系统，
// 这个类完全不需要改动；而且基于接口而非实现编程，代码的可测试性更好。
public class RiskManagement {
    private List<ISensitiveWordsFilter> filters = new ArrayList<>();

    public void addSensitiveWordsFilter(ISensitiveWordsFilter filter) {
        filters.add(filter);
    }

    public String filterSensitiveWords(String text) {
        String maskedText = text;
        for (ISensitiveWordsFilter filter : filters) {
            maskedText = filter.filter(maskedText);
        }
        return maskedText;
    }
}

当依赖的外部系统发生变化时，只需要基于之前的API设计接口，并通过适配器完成适配即可以少量代码的修改完成替换。
兼容老版本代码
将不同类型的数据转化为同一种类型

适配器模式是一种事后的补救策略。适配器提供跟原始类不同的接口，而代理模式、装饰器模式提供的都是跟原始类相同的接口。

门面模式

为了保证接口的可复用性（或者叫通用性），需要将接口尽量设计得细粒度一点，职责单一一点。但是，如果接口的粒度过小，在接口的使用者开发一个业务功能时，就会导致需要调用 n 多细粒度的接口才能完成。
相反，如果接口粒度设计得太大，一个接口返回 n 多数据，要做 n 多事情，就会导致接口不够通用、可复用性不好。接口不可复用，那针对不同的调用者的业务需求，就需要开发不同的接口来满足，这就会导致系统的接口无限膨胀。
门面模式（外观模式）就是用来解决接口的可复用性（通用性）和易用性之间的矛盾。
门面模式根据当前系统给其他系统提供的功能，有选择性的将API封装成接口、或者将多个API按照顺序依次封装进新的API提供给其他系统调用。

组合模式

组合模式并不是简单的为多个类的组合关系，主要是用来处理能表示成树形结构的对象集合数据。
将一组对象（文件和目录）组织成树形结构，以表示一种‘部分 - 整体’的层次结构（目录与子目录的嵌套结构）。组合模式让客户端可以统一单个对象（文件）和组合对象（目录）的处理逻辑（递归遍历）

文件系统中，文件和目录都可以使用同一个节点类来表示，但是从扩展性（文件或目录可能会对应不同的操作）、业务建模（文件和目录从业务上是两个概念）、代码的可读性（文件和目录区分对待更加符合人们对业务的认知）的角度来说，最好对文件和目录进行区分设计，定义为 File 和 Directory两个类。

//动态地添加、删除某个目录下的子目录或文件；
//统计指定目录下的文件个数；
//统计指定目录下的文件总大小。
public abstract class FileSystemNode {  // 树结构类中根类，定义通用属性、通用方法和抽象方法
    protected String path;

    public FileSystemNode(String path) {
        this.path = path;
    }

    public abstract int countNumOfFiles();

    public abstract long countSizeOfFiles();

    public String getPath() {
        return path;
    }
}

public class File extends FileSystemNode {  // 树结构中文件类
    public File(String path) {
        super(path);
    }

    @Override
    public int countNumOfFiles() {  // 不同节点的实现方式不一样
        return 1;
    }

    @Override
    public long countSizeOfFiles() {
        java.io.File file = new java.io.File(path);
        if (!file.exists()) return 0;
        return file.length();
    }
}

public class Directory extends FileSystemNode {
    private List<FileSystemNode> subNodes = new ArrayList<>();  // 不同节点的属性也不同

    public Directory(String path) {
        super(path);
    }

    @Override
    public int countNumOfFiles() {
        int numOfFiles = 0;
        for (FileSystemNode fileOrDir : subNodes) {
            numOfFiles += fileOrDir.countNumOfFiles();
        }
        return numOfFiles;
    }

    @Override
    public long countSizeOfFiles() {
        long sizeofFiles = 0;
        for (FileSystemNode fileOrDir : subNodes) {
            sizeofFiles += fileOrDir.countSizeOfFiles();
        }
        return sizeofFiles;
    }

    public void addSubNode(FileSystemNode fileOrDir) {
        subNodes.add(fileOrDir);
    }

    public void removeSubNode(FileSystemNode fileOrDir) {
        int size = subNodes.size();
        int i = 0;
        for (; i < size; ++i) {
            if (subNodes.get(i).getPath().equalsIgnoreCase(fileOrDir.getPath())) {
                break;
            }
        }
        if (i < size) {
            subNodes.remove(i);
        }
    }
}

享元模式

享元模式的意图是复用对象，节省内存，前提是享元对象是不可变对象。
具体来讲，当一个系统中存在大量重复对象的时候，如果这些重复的对象是不可变对象，可以利用享元模式将对象设计成享元，在内存中只保留一份实例，供多处代码引用。这样可以减少内存中对象的数量，起到节省内存的目的。实际上，不仅仅相同对象可以设计成享元，对于相似对象，也可以将这些对象中相同的部分（字段）提取出来，设计成享元，让这些大量相似对象引用这些享元。

不可变对象一旦通过构造函数初始化完成之后，它的状态（对象的成员变量或者属性）就不会再被修改了。所以，不可变对象不能暴露任何 set() 等修改内部状态的方法。之所以要求享元是不可变对象，那是因为它会被多处代码共享使用，避免一处代码对享元进行了修改，影响到其他使用它的代码。

比如java中基本数据类型的各个整型包装类Integer、Byte，Integer中有一个缓存池保持了职值为-128-127的常用对象。

   public static Integer valueOf(int i) {
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

享元模式跟缓存的区别在于，享元在于复用、共享，而缓存在于提高访问效率。

行为型模式

创建型设计模式主要解决“对象的创建”问题，结构型设计模式主要解决“类或对象的组合或组装”问题，那行为型设计模式主要解决的就是“类或对象之间的交互”问题

观察者模式

观察者模式也被称为发布订阅模式。在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会自动收到通知。一般情况下，被依赖的对象叫作被观察者，依赖的对象叫作观察者。

// 模板代码，反映了反映大体的设计思路在真实的软件开发中，并不需要照搬上面的模板代码。
// 观察者模式的实现方法各式各样，函数、类的命名等会根据业务场景的不同有很大的差别，比如register 函数还可以叫作 attach，remove 函数还可以叫作 detach 等等
public interface Subject {
    void registerObserver(Observer observer);

    void removeObserver(Observer observer);

    void notifyObservers(Message message);
}

public interface Observer {
    void update(Message message);
}

public class ConcreteSubject implements Subject {
    private List<Observer> observers = new ArrayList<Observer>();

    @Override
    public void registerObserver(Observer observer) {
        observers.add(observer);
    }

    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }

    @Override
    public void notifyObservers(Message message) {
        for (Observer observer : observers) {
            observer.update(message);
        }
    }

}

public class ConcreteObserverOne implements Observer {
    @Override
    public void update(Message message) {
        //TODO: 获取消息通知，执行自己的逻辑...
        System.out.println("ConcreteObserverOne is notified.");
    }
}

public class ConcreteObserverTwo implements Observer {
    @Override
    public void update(Message message) {
        //TODO: 获取消息通知，执行自己的逻辑...
        System.out.println("ConcreteObserverTwo is notified.");
    }
}

public class Demo {
    public static void main(String[] args) {
        ConcreteSubject subject = new ConcreteSubject();
        subject.registerObserver(new ConcreteObserverOne());
        subject.registerObserver(new ConcreteObserverTwo());
        subject.notifyObservers(new Message());
    }
}

上述模板方法以一种同步阻塞的方法实现通知，还可以已异步非阻塞的方式实现。

模板模式

步骤化、规范化（规范化每个流程的入参，出参）算法流程，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤。

分离：将功能步骤化，抽取业务方法和通用方法
瘦身：通用方法可由抽象类或者功能支撑类实现（功能支撑类继承抽象类），数据和配置分别交给数据支撑类、配置支撑类完成；瘦身后可以避免抽象类太过臃肿，难以维护
就近：属于谁的就交给谁来实现

首先有一个接口类（IDrawExec）：定义功能
支撑类：数据支撑类（DrawStrategySupport，给模板标准方法其他一些操作数据的方法，主要提供给抽象类 AbstractDrawBase 所需的一些数据库层、Redis层以及其他的简单数据支撑（这些数据支撑类往往是用于获取数据，如果要保存数据，一般由具体的实现），具体逻辑实现是抽象类的子类实现，流程标准是抽象类定义。）、配置支撑类（DrawConfig，工厂方法提供两种策略模式对象）、功能支撑类（继承模板类，实现一些通用方法）
模板类标准接口方法：AbstractDrawBase，实现接口中功能，将功能业务步骤化，判断哪些步骤可能根据的情况有不同的实现方式，那么就将这些步骤抽取为抽象方法，交给具体的业务实现类实现；通用的方法就可以在本抽象类中实现，同时部分也可以交给抽象类的继承类实现（单一职责原则）
业务类：实现抽象的业务方法

作用：

复用，模板模式把一个算法中不变的流程抽象到父类的模板方法中，将可变的部分method1()、method2() 留给子类 ContreteClass1 和 ContreteClass2 来实现。所有的子类都可以复用父类中模板方法定义的流程代码。
扩展，
回调，

策略模式

定义一组算法类，将每个算法分别封装起来，让它们可以互相替换。
策略类定义：包含一个策略接口和一组实现这个接口的策略类。

public interface Strategy {  // 策略接口
    void algorithmInterface();
}

public class ConcreteStrategyA implements Strategy {  // 策略类A
    @Override
    public void algorithmInterface() {
        //具体的算法...
    }
}

public class ConcreteStrategyB implements Strategy {  // 策略类B
    @Override

    public void algorithmInterface() {
        //具体的算法...
    }
}

创建策略：由于通常包含多个策略类，因此在创建策略对象的时候需要通过类型type来判断选择那个策略类，通常通过工厂模式来创建策略对象。

// 当策略类为无状态类，即无属性的类，该策略类可以共享，可以使用缓存的方式
public class StrategyFactory {
// 通过map的方式来替换if-else分支判断
    private static final Map<String, Strategy> strategies = new HashMap<>();

    static {
        strategies.put("A", new ConcreteStrategyA());
        strategies.put("B", new ConcreteStrategyB());
    }

    public static Strategy getStrategy(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        return strategies.get(type);
    }
}

//当有状态时，每次都需要创建一个新的策略类供使用
public class StrategyFactory {
    public static Strategy getStrategy(String type) {

        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }

        if (type.equals("A")) {
            return new ConcreteStrategyA();
        } else if (type.equals("B")) {
            return new ConcreteStrategyB();
        }

        return null;
    }
}

使用策略：通过传递的类型来让工厂类提供策略类。

职责链模式

多个处理器（接收对象）依次处理同一个请求。一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条。链条上的每个处理器各自承担各自的处理职责，所以叫作职责链模式。
第一种实现使用链表的形式来存储处理器，通过链表的后继节点来依次选择处理器。

// Handler 是所有处理器类的抽象父类
public abstract class Handler {
    protected Handler successor = null;  // 处理器链中的后继节点

    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }

    public abstract void handle();  // 抽象方法，每个处理器的处理逻辑
}

public class HandlerA extends Handler {
    @Override
    public boolean handle() {
        boolean handled = false;
        //...
        if (!handled && successor != null) {  // 当前处理器能处理该请求，就不继续往下传递；如果不能处理，则交由后面的处理器来处理，也就是调用 successor.handle()）
            successor.handle();
        }
    }
}

public class HandlerB extends Handler {
    @Override
    public void handle() {
        boolean handled = false;
        //...
        if (!handled && successor != null) {
            successor.handle();  // 这个必须要有，当这个没有的时候则没有处理器进行处理，从而出现bug
        }
    }
}

// 处理器链，链表的形式，首尾节点，每次在尾节点添加节点
public class HandlerChain {
    private Handler head = null;
    private Handler tail = null;

    public void addHandler(Handler handler) {
        handler.setSuccessor(null);

        if (head == null) {
            head = handler;
            tail = handler;
            return;
        }

        tail.setSuccessor(handler);
        tail = handler;
    }

    public void handle() {
        if (head != null) {
            head.handle();
        }
    }
}

// 使用举例
public class Application {
    public static void main(String[] args) {
        HandlerChain chain = new HandlerChain();
        chain.addHandler(new HandlerA());
        chain.addHandler(new HandlerB());
        chain.handle();
    }
}

// 处理器类的改进版，使用
public abstract class Handler {
    protected Handler successor = null;

    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }

    public final void handle() {  // 模板模式定义处理器处理逻辑
        boolean handled = doHandle();  // 每个处理器处理请求的方法，由具体的处理器实现
        if (successor != null && !handled) {
            successor.handle();
        }
    }

    protected abstract boolean doHandle();
}

public class HandlerA extends Handler {
    @Override
    protected boolean doHandle() {
        boolean handled = false;
        //...
        return handled;
    }
}

第二种实现方式使用数组来保存处理器，使用foreach的方式来遍历选择处理器

public interface IHandler {
    boolean handle();
}

public class HandlerA implements IHandler {
    @Override
    public boolean handle() {
        boolean handled = false;
        //...
        return handled;
    }
}

public class HandlerB implements IHandler {
    @Override
    public boolean handle() {
        boolean handled = false;
        //...
        return handled;
    }
}

public class HandlerChain {
    private List<IHandler> handlers = new ArrayList<>();

    public void addHandler(IHandler handler) {
        this.handlers.add(handler);
    }

    public void handle() {
        for (IHandler handler : handlers) {
            boolean handled = handler.handle();
            if (handled) {
                break;
            }
        }
    }
}

当处理器链中的所有处理器都需要对请求进行处理时，只需要进行简单的修改即可，比如过滤器和拦截器就是基于此。

public final void handle() {
    doHandle();
    if (successor != null) {
        successor.handle();
    }
}

迭代器模式

用于遍历数组和集合。通过游标的方式实现。

状态模式

状态模式一般用来表示状态流转，通常包括三部分：状态（State）、事件（Event）、动作（Action），可以替换大量的if-else判断。

yq15797688367

关注

9
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
常用设计模式

可以在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码，解决bug，：代码容易理解，不会存在很多疑问。可以从是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等方面评估。：在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。可复用性：尽量减少重复代码的编写，复用已有的代码。继承和多态就是体现了可复用性。重复不一定是代码一样，也不一定代码不一样就不算重复。
复制链接

扫一扫