重学 Java 设计模式:实战备忘录模式「模拟互联网系统上线过程中,配置文件回滚场景」

简介: 实现不了,有时候是功能复杂度较高难以实现,有时候是工期较短实现不完。而编码的行为又是一个不太好量化的过程,同样一个功能每个人的实现方式不一样,遇到开发问题解决问题的速度也不一样。除此之外还很不好给产品解释具体为什么要这个工期时间,这就像盖楼的图纸最终要多少水泥砂浆一样。那么这时研发会尽可能的去通过一些经验,制定流程规范、设计、开发、评审等,确定一个可以完成的时间范围,又避免风险的时间点后。再被压缩,往往会出一些矛盾点,能压缩要解释为什么之前要那么多时间,不能压缩又有各方不断施加的压力。因此有时候不一定是借口,是要考虑如何让整个团队健康的发展。

目录


  • 一、前言
  • 二、开发环境
  • 三、备忘录模式介绍
  • 四、案例场景模拟
  • 五、备忘录模式记录配置文件版本信息
  • 1. 工程结构
  • 2. 代码实现
  • 3. 测试验证
  • 六、总结


一、前言

实现不了是研发的借口?

实现不了,有时候是功能复杂度较高难以实现,有时候是工期较短实现不完。而编码的行为又是一个不太好量化的过程,同样一个功能每个人的实现方式不一样,遇到开发问题解决问题的速度也不一样。除此之外还很不好给产品解释具体为什么要这个工期时间,这就像盖楼的图纸最终要多少水泥砂浆一样。那么这时研发会尽可能的去通过一些经验,制定流程规范、设计、开发、评审等,确定一个可以完成的时间范围,又避免风险的时间点后。再被压缩,往往会出一些矛盾点,能压缩要解释为什么之前要那么多时间,不能压缩又有各方不断施加的压力。因此有时候不一定是借口,是要考虑如何让整个团队健康的发展。

鼓励有时比压力要重要!

在学习的过程中,很多时候我们听到的都是,你要怎样,怎样,你瞧瞧谁谁谁,哪怕今天听不到这样的声音了,但因为曾经反复听到过而导致内心抗拒。虽然也知道自己要去学,但是很难坚持,学着学着就没有了方向,看到还有那么多不会的就更慌了,以至于最后心态崩了,更不愿意学。其实程序员的压力并不小,想成长几乎是需要一直的学习,就像似乎再也不敢说精通java了一样,知识量实在是随着学习的深入,越来越深,越来越广。所以需要,开心学习,快乐成长!

临阵的你好像一直很着急!

经常的听到;老师明天就要了你帮我弄弄吧你给我写一下完事我就学这次着急现在这不是没时间学吗快给我看看。其实看到的类似的还有很多,很纳闷你的着急怎么来的,不太可能,人在家中坐,祸从天上落。老师怎么就那个时间找你了,老板怎么就今天管你要了,还不是日积月累你没有学习,临时抱佛脚乱着急!即使后来真的有人帮你了,但最好不要放松,要尽快学会,躲得过初一还有初二呢!

二、开发环境

  1. JDK 1.8
  2. Idea + Maven
  3. 涉及工程一个,可以通过关注「公众号」bugstack虫洞栈,回复源码下载获取(打开获取的链接,找到序号18)
工程 描述
itstack-demo-design-17-00 开发配置文件备忘录

三、备忘录模式介绍

24.jpg

备忘录模式,图片来自 refactoringguru.cn

备忘录模式是以可以恢复或者说回滚,配置、版本、悔棋为核心功能的设计模式,而这种设计模式属于行为模式。在功能实现上是以不破坏原对象为基础增加备忘录操作类,记录原对象的行为从而实现备忘录模式。

这个设计在我们平常的生活或者开发中也是比较常见的,比如:后悔药、孟婆汤(一下回滚到0),IDEA编辑和撤销、小霸王游戏机存档。当然还有我们非常常见的Photoshop,如下;

25.jpg

Photoshop 历史记录

四、案例场景模拟

26.jpg

场景模拟;系统发布上线配置回滚

「在本案例中我们模拟系统在发布上线的过程中记录线上配置文件用于紧急回滚」

在大型互联网公司系统的发布上线一定是易用、安全、可处理紧急状况的,同时为了可以隔离线上和本地环境,一般会把配置文件抽取出来放到线上,避免有人误操作导致本地的配置内容发布出去。同时线上的配置文件也会在每次变更的时候进行记录,包括;版本号、时间、MD5、内容信息和操作人。

在后续上线时如果发现紧急问题,系统就会需要回滚操作,如果执行回滚那么也可以设置配置文件是否回滚。因为每一个版本的系统可能会随着带着一些配置文件的信息,这个时候就可以很方便的让系统与配置文件一起回滚操作。

我们接下来就使用备忘录模式,模拟如何记录配置文件信息。实际的使用过程中还会将信息存放到库中进行保存,这里暂时只是使用内存记录。

五、备忘录模式记录配置文件版本信息

备忘录的设计模式实现方式,重点在于不更改原有类的基础上,增加备忘录类存放记录。可能平时虽然不一定非得按照这个设计模式的代码结构来实现自己的需求,但是对于功能上可能也完成过类似的功能,记录系统的信息。

除了现在的这个案例外,还可以是运营人员在后台erp创建活动对信息的记录,方便运营人员可以上下修改自己的版本,而不至于因为误操作而丢失信息。

1. 工程结构

itstack-demo-design-17-00
└── src
    ├── main
    │   └── java
    │       └── org.itstack.demo.design
    │           ├── Admin.java
    │           ├── ConfigFile.java
    │           ├── ConfigMemento.java
    │           └── ConfigOriginator.java
    └── test
        └── java
            └── org.itstack.demo.design.test
                └── ApiTest.java

「备忘录模式模型结构」

27.jpg

备忘录模式模型结构

  • 以上是工程结构的一个类图,其实相对来说并不复杂,除了原有的配置类(ConfigFile)以外,只新增加了三个类。
  • ConfigMemento:备忘录类,相当于是对原有配置类的扩展
  • ConfigOriginator:记录者类,获取和返回备忘录类对象信息
  • Admin:管理员类,用于操作记录备忘信息,比如你一些列的顺序执行了什么或者某个版本下的内容信息

2. 代码实现

2.1 配置信息类

public class ConfigFile {
    private String versionNo; // 版本号
    private String content;   // 内容
    private Date dateTime;    // 时间
    private String operator;  // 操作人
    // ...get/set
}
  • 配置类可以是任何形式的,这里只是简单的描述了一个基本的配置内容信息。

2.2 备忘录类

public class ConfigMemento {
    private ConfigFile configFile;
    public ConfigMemento(ConfigFile configFile) {
        this.configFile = configFile;
    }
    public ConfigFile getConfigFile() {
        return configFile;
    }
    public void setConfigFile(ConfigFile configFile) {
        this.configFile = configFile;
    }
}
  • 备忘录是对原有配置类的扩展,可以设置和获取配置信息。

2.3 记录者类

public class ConfigOriginator {
    private ConfigFile configFile;
    public ConfigFile getConfigFile() {
        return configFile;
    }
    public void setConfigFile(ConfigFile configFile) {
        this.configFile = configFile;
    }
    public ConfigMemento saveMemento(){
        return new ConfigMemento(configFile);
    }
    public void getMemento(ConfigMemento memento){
        this.configFile = memento.getConfigFile();
    }
}
  • 记录者类除了对ConfigFile配置类增加了获取和设置方法外,还增加了保存saveMemento()、获取getMemento(ConfigMemento memento)
  • saveMemento:保存备忘录的时候会创建一个备忘录信息,并返回回去,交给管理者处理。
  • getMemento:获取的之后并不是直接返回,而是把备忘录的信息交给现在的配置文件this.configFile,这部分需要注意。

2.4 管理员类

public class Admin {
    private int cursorIdx = 0;
    private List<ConfigMemento> mementoList = new ArrayList<ConfigMemento>();
    private Map<String, ConfigMemento> mementoMap = new ConcurrentHashMap<String, ConfigMemento>();
    public void append(ConfigMemento memento) {
        mementoList.add(memento);
        mementoMap.put(memento.getConfigFile().getVersionNo(), memento);
        cursorIdx++;
    }
    public ConfigMemento undo() {
        if (--cursorIdx <= 0) return mementoList.get(0);
        return mementoList.get(cursorIdx);
    }
    public ConfigMemento redo() {
        if (++cursorIdx > mementoList.size()) return mementoList.get(mementoList.size() - 1);
        return mementoList.get(cursorIdx);
    }
    public ConfigMemento get(String versionNo){
        return mementoMap.get(versionNo);
    }
}
  • 在这个类中主要实现的核心功能就是记录配置文件信息,也就是备忘录的效果,之后提供可以回滚和获取的方法,拿到备忘录的具体内容。
  • 同时这里设置了两个数据结构来存放备忘录,实际使用中可以按需设置。List<ConfigMemento>Map<String, ConfigMemento>
  • 最后是提供的备忘录操作方法;存放(append)、回滚(undo)、返回(redo)、定向获取(get),这样四个操作方法。

3. 测试验证

3.1 编写测试类

@Test
public void test() {
    Admin admin = new Admin();
    ConfigOriginator configOriginator = new ConfigOriginator();
    configOriginator.setConfigFile(new ConfigFile("1000001", "配置内容A=哈哈", new Date(), "小傅哥"));
    admin.append(configOriginator.saveMemento()); // 保存配置
    configOriginator.setConfigFile(new ConfigFile("1000002", "配置内容A=嘻嘻", new Date(), "小傅哥"));
    admin.append(configOriginator.saveMemento()); // 保存配置
    configOriginator.setConfigFile(new ConfigFile("1000003", "配置内容A=么么", new Date(), "小傅哥"));
    admin.append(configOriginator.saveMemento()); // 保存配置
    configOriginator.setConfigFile(new ConfigFile("1000004", "配置内容A=嘿嘿", new Date(), "小傅哥"));
    admin.append(configOriginator.saveMemento()); // 保存配置  
    // 历史配置(回滚)
    configOriginator.getMemento(admin.undo());
    logger.info("历史配置(回滚)undo:{}", JSON.toJSONString(configOriginator.getConfigFile()));  
    // 历史配置(回滚)
    configOriginator.getMemento(admin.undo());
    logger.info("历史配置(回滚)undo:{}", JSON.toJSONString(configOriginator.getConfigFile()));  
    // 历史配置(前进)
    configOriginator.getMemento(admin.redo());
    logger.info("历史配置(前进)redo:{}", JSON.toJSONString(configOriginator.getConfigFile()));   
    // 历史配置(获取)
    configOriginator.getMemento(admin.get("1000002"));
    logger.info("历史配置(获取)get:{}", JSON.toJSONString(configOriginator.getConfigFile()));
}
  • 这个设计模式的学习有一部分重点是体现在了单元测试类上,这里包括了四次的信息存储和备忘录历史配置操作。
  • 通过上面添加了四次配置后,下面分别进行操作是;回滚1次再回滚1次之后向前进1次最后是获取指定的版本配置。具体的效果可以参考测试结果。

3.2 测试结果

23:12:09.512 [main] INFO  org.itstack.demo.design.test.ApiTest - 历史配置(回滚)undo:{"content":"配置内容A=嘿嘿","dateTime":159209829432,"operator":"小傅哥","versionNo":"1000004"}
23:12:09.514 [main] INFO  org.itstack.demo.design.test.ApiTest - 历史配置(回滚)undo:{"content":"配置内容A=么么","dateTime":159209829432,"operator":"小傅哥","versionNo":"1000003"}
23:12:09.514 [main] INFO  org.itstack.demo.design.test.ApiTest - 历史配置(前进)redo:{"content":"配置内容A=嘿嘿","dateTime":159209829432,"operator":"小傅哥","versionNo":"1000004"}
23:12:09.514 [main] INFO  org.itstack.demo.design.test.ApiTest - 历史配置(获取)get:{"content":"配置内容A=嘻嘻","dateTime":159320989432,"operator":"小傅哥","versionNo":"1000002"}
Process finished with exit code 0
  • 从测试效果上可以看到,历史配置按照我们的指令进行了回滚和前进,以及最终通过指定的版本进行获取,符合预期结果。

六、总结

  • 此种设计模式的方式可以满足在不破坏原有属性类的基础上,扩充了备忘录的功能。虽然和我们平时使用的思路是一样的,但在具体实现上还可以细细品味,这样的方式在一些源码中也有所体现。
  • 在以上的实现中我们是将配置模拟存放到内存中,如果关机了会导致配置信息丢失,因为在一些真实的场景里还是需要存放到数据库中。那么此种存放到内存中进行回复的场景也不是没有,比如;Photoshop、运营人员操作ERP配置活动,那么也就是即时性的一般不需要存放到库中进行恢复。另外如果是使用内存方式存放备忘录,需要考虑存储问题,避免造成内存大量消耗。
  • 设计模式的学习都是为了更好的写出可扩展、可管理、易维护的代码,而这个学习的过程需要自己不断的尝试实际操作,理论的知识与实际结合还有很长一段距离。切记多多上手!
目录
相关文章
|
14天前
|
设计模式 存储 缓存
「全网最细 + 实战源码案例」设计模式——享元模式
享元模式(Flyweight Pattern)是一种结构型设计模式,旨在减少大量相似对象的内存消耗。通过分离对象的内部状态(可共享、不变)和外部状态(依赖环境、变化),它有效减少了内存使用。适用于存在大量相似对象且需节省内存的场景。模式优点包括节省内存和提高性能,但会增加系统复杂性。实现时需将对象成员变量拆分为内在和外在状态,并通过工厂类管理享元对象。
147 83
|
10天前
|
设计模式 存储 算法
「全网最细 + 实战源码案例」设计模式——命令模式
命令模式(Command Pattern)是一种行为型设计模式,将请求封装成独立对象,从而解耦请求方与接收方。其核心结构包括:Command(命令接口)、ConcreteCommand(具体命令)、Receiver(接收者)和Invoker(调用者)。通过这种方式,命令的执行、撤销、排队等操作更易扩展和灵活。 适用场景: 1. 参数化对象以操作。 2. 操作放入队列或远程执行。 3. 实现回滚功能。 4. 解耦调用者与接收者。 优点: - 遵循单一职责和开闭原则。 - 支持命令组合和延迟执行。 - 可实现撤销、恢复功能。 缺点: - 增加复杂性和类数量。
48 14
「全网最细 + 实战源码案例」设计模式——命令模式
|
10天前
|
设计模式 存储 Java
「全网最细 + 实战源码案例」设计模式——责任链模式
责任链模式(Chain of Responsibility Pattern)是一种行为型设计模式,允许将请求沿着处理者链进行发送。每个处理者可以处理请求或将其传递给下一个处理者,从而实现解耦和灵活性。其结构包括抽象处理者(Handler)、具体处理者(ConcreteHandler)和客户端(Client)。适用于不同方式处理不同种类请求、按顺序执行多个处理者、以及运行时改变处理者及其顺序的场景。典型应用包括日志处理、Java Web过滤器、权限认证等。
47 13
「全网最细 + 实战源码案例」设计模式——责任链模式
|
12天前
|
设计模式 算法 开发者
「全网最细 + 实战源码案例」设计模式——策略模式
策略模式(Strategy Pattern)是一种行为型设计模式,用于定义一系列可替换的算法或行为,并将它们封装成独立的类。通过上下文持有策略对象,在运行时动态切换算法,提高代码的可维护性和扩展性。适用于需要动态切换算法、避免条件语句、经常扩展算法或保持算法独立性的场景。优点包括符合开闭原则、运行时切换算法、解耦上下文与策略实现、减少条件判断;缺点是增加类数量和策略切换成本。示例中通过定义抽象策略接口和具体策略类,结合上下文类实现动态算法选择。
47 8
「全网最细 + 实战源码案例」设计模式——策略模式
|
12天前
|
设计模式 SQL 算法
「全网最细 + 实战源码案例」设计模式——模板方法模式
模板方法模式是一种行为型设计模式,定义了算法的骨架并在父类中实现不变部分,将可变部分延迟到子类实现。通过这种方式,它避免了代码重复,提高了复用性和扩展性。具体步骤由抽象类定义,子类实现特定逻辑。适用于框架设计、工作流和相似算法结构的场景。优点包括代码复用和符合开闭原则,缺点是可能违反里氏替换原则且灵活性较低。
60 7
「全网最细 + 实战源码案例」设计模式——模板方法模式
|
18天前
|
设计模式 Java 开发者
「全网最细 + 实战源码案例」设计模式——适配器模式
适配器模式(Adapter Pattern)是一种结构型设计模式,通过引入适配器类将一个类的接口转换为客户端期望的另一个接口,使原本因接口不兼容而无法协作的类能够协同工作。适配器模式分为类适配器和对象适配器两种,前者通过多重继承实现,后者通过组合方式实现,更常用。该模式适用于遗留系统改造、接口转换和第三方库集成等场景,能提高代码复用性和灵活性,但也可能增加代码复杂性和性能开销。
67 28
|
14天前
|
设计模式 存储 安全
「全网最细 + 实战源码案例」设计模式——组合模式
组合模式(Composite Pattern)是一种结构型设计模式,用于将对象组合成树形结构以表示“部分-整体”的层次结构。它允许客户端以一致的方式对待单个对象和对象集合,简化了复杂结构的处理。组合模式包含三个主要组件:抽象组件(Component)、叶子节点(Leaf)和组合节点(Composite)。通过这种模式,客户端可以统一处理简单元素和复杂元素,而无需关心其内部结构。适用于需要实现树状对象结构或希望以相同方式处理简单和复杂元素的场景。优点包括支持树形结构、透明性和遵循开闭原则;缺点是可能引入不必要的复杂性和过度抽象。
72 22
|
18天前
|
设计模式 缓存 Java
「全网最细 + 实战源码案例」设计模式——代理模式
代理模式(Proxy Pattern)是一种结构型设计模式,通过代理对象控制对目标对象的访问并添加额外功能。它分为静态代理和动态代理,后者包括JDK动态代理和CGLIB动态代理。JDK动态代理基于接口反射生成代理类,而CGLIB通过继承目标类生成子类。代理模式适用于延迟初始化、访问控制、远程服务、日志记录和缓存等场景,优点是职责分离、符合开闭原则和提高安全性,缺点是增加系统复杂性。
69 25
|
16天前
|
设计模式 前端开发 数据库
「全网最细 + 实战源码案例」设计模式——桥接模式
桥接模式(Bridge Pattern)是一种结构型设计模式,通过将抽象部分与实现部分分离,使它们可以独立变化,从而降低代码耦合度,避免类爆炸,提高可扩展性。其结构包括实现类接口、具体实现类、抽象类和精确抽象类。适用于多维度扩展类、隐藏实现细节、简化庞杂类以及运行时切换实现方法的场景。优点包括高扩展性、隐藏实现细节、遵循开闭原则和单一职责原则;缺点是可能增加代码复杂度。示例中展示了不同操作系统播放不同格式视频文件的实现。
46 19
|
16天前
|
设计模式 存储
「全网最细 + 实战源码案例」设计模式——装饰者模式
装饰者模式(Decorator Pattern)是一种结构型设计模式,通过“包装”现有对象来为其添加额外功能,而无需修改原有代码。它通过创建装饰类来扩展对象的功能,而非继承。该模式由抽象构件、具体构件、抽象装饰者和具体装饰者组成,允许在运行时动态组合功能。穿衣服的例子很好地解释了装饰者模式:你可以根据需要一层层添加衣物,如毛衣、夹克和雨衣,每件衣物都扩展了基本行为,但不是你的一部分,可以随时脱掉。 优点包括灵活性、避免子类爆炸和符合开闭原则;缺点是可能增加复杂性和难以理解。适用于希望在不修改代码的情况下为对象新增行为的场景,尤其当继承难以实现或不可行时。
50 15

热门文章

最新文章