白泽的博客

如果这一时间点没有对应的全量备份，就先找到最近的一次全量备份，然后用它来恢复，之后执行此次全量备份跟这一时间点之间的所有增量备份，也就是对应的操作或者数据变动。针对这个问题，不同的业务场景有不同的处理方式。备忘录模式通过封装对象的内部状态，提供了一种灵活且安全的状态管理机制，非常适合用于需要保存和恢复状态的复杂系统中，比如在需要实现撤销操作或保存和恢复对象状态的场景，例如文本编辑器、游戏状态保存等。在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态。

命令模式的主要作用和应用场景，是用来控制命令的执行，比如，异步、延迟、排队执行命令、撤销重做命令、存储命令、给命令记录日志等等，这才是命令模式能发挥作用的地方。

容器对象的遍历与其内部表示分离，可以更好的支持对容器对象的多种遍历算法，并且可以在不修改容器对象本身的前提下增加新的遍历方式。目的是将容器对象的遍历与其内部表示分离，可以更好的支持对容器对象的多种遍历算法，并且可以在不修改容器对象本身的前提下增加新的遍历方式。而且每个迭代器独享自己的游标信息，就可以创建多个迭代器，同时对一个容器进行遍历。通过迭代器来遍历集合元素的同时，如果增加或者删除集合中的元素，有可能会导致某个元素被重复遍历或遍历不到，也有可能正常遍历（运行结果的对错，要视情况而定），这种情况称为。

多态表示执行哪个对象的方法，重载表示执行对象的哪个方法。由于 Kotlin 是单分派机制，所以重载代码那里匹配的是 SingleDispatch 的 overloadFunction(p: Parent) 函数，也就是根据 p 的声明类型来决定匹配哪个重载函数，而不是运行时真实类型。总的来说，访问者模式是一种强大的设计模式，它允许在不修改对象结构的情况下增加新的操作，但在使用时需要权衡其带来的复杂性和性能开销。，从而绕过了单分派机制语言的限制，这虽然不是完整的访问者模式，但已包含访问者模式的核心原理了。

策略模式（Strategy Pattern）的定义比较简单，主要是一个策略接口和一组实现这个接口的策略类。基于“面向对象的多态特性”和“面向接口编程”的原则，在运行时根据场景灵活选择具体策略。

在移动开发中，有很多知名的三方库也应用了观察者模式，比如 EventBus、RxJava、ARouter、Lifecycle 等，它们都符合观察者模式的思想，只是实现方式会有不同，下面以 EventBus 为例，看它是如何实现的。EventBus 核心维护了一个映射表，在 register 时遍历注册对象中 Subscribe 注解的方法，并将方法消息类型和对应方法存入映射表，在 post 时查询映射表，找到对应消息类型匹配的方法，并通过反射调用的方式进行通知，这就是 EventBus 的设计思想。

模板模式的原理和实现非常简单，在平时的编码中，可能不经意间就已经用到了模板模式。模板方法的目的就是加强代码复用和方便扩展，原理和实现简单，应用也非常广泛，比如 Java 的 AbstractList、AbstractMap；在移动端开发中也经常定义出。模板模式是经常使用的设计模式，它使得算法的结构在高层得到定义，而具体的实现细节则可以在低层通过子类来实现，符合开闭原则，让代码可复用，扩展方便。不过在 Kotlin 语言中，，回到模板方法模式，要注意封装类设计的合理性，避免职责混杂，具体设计要根据场景而定。

责任链模式（Chain of Responsibility Pattern）也叫职责链模式，通过将请求的处理分配给一系列的处理对象，这些处理对象通过链式结构组织起来，以实现对请求的灵活处理。比如，一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条，链条上的每个处理器承担各自的处理职责。

享元模式（Flyweight Pattern）核心思想是通过共享对象方式，达到节省内存和提高性能的目的。享元对象需是不可变对象，因为它会被多处代码共享使用，要避免一处代码对享元进行了修改，影响到其他使用它的代码。

组合模式（Composite Pattern）也叫部分-整体模式（Part-Whole）， 用来描述部分与整体的关系，主要是用于处理树形结构数据。

借助设计模式，可以利用更好的代码结构，将大块复杂代码拆分成职责更单一的小类，让其满足开闭原则、高内聚松耦合等特性，以此来控制和应对代码的复杂性，提高代码的可扩展性。

设计原则是软件编码时所遵循的规则，旨在帮助开发者创建出既满足功能需求又易于维护、可扩展且美观的设计，理解设计原则可以提升代码质量、减少错误以及促进团队协作，但对设计原则的理解要灵活，不要拿原则当真理，生搬硬套会适得其反。

门面模式（Facade Pattern），也称作外观模式，主要用于为复杂的子系统提供一个统一的、更简洁的接口，使得子系统更加容易使用，并减少系统的相互依赖，提高系统的灵活性和可维护性。

适配器模式（Adapter Pattern）允许将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。简单来说，适配器解决的就是接口不兼容问题，引入适配器充当中间桥梁，从而让不兼容接口协同工作。

装饰器模式（Decorator Pattern）允许在不修改原有类代码的情况下，通过创建一系列包装类来给对象动态地添加一些额外的功能，且增强的功能支持相互叠加。装饰器模式将“组合优于继承”的思想体现的淋漓尽致，当原始类需要增加额外功能时，相比直接生成子类的实现方式，这种模式更为灵活。

举个例子，应用性能监控的告警系统：根据告警规则，触发不同级别的消息通知，如SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）。可见 notify 方法中每个分支中的代码逻辑都比较复杂，发送通知的所有逻辑都扎堆在 NotificationOld 类中，如果新增消息级别和通知渠道，则又要改动分支代码，可能影响原有逻辑，也不符合开闭原则。桥接模式（Bridge Pattern）的主要目的是解耦，创建一个抽象层来隔离接口与实现，让它们之间的依赖关系可以通过对象的组合来替代继承，从而达到解耦的目的。

代理的实现有两种方式，一是实现同一接口，二是直接继承。代理又分为静态代理和动态代理，动态代理的动态指的是不需要提前创建代理类，只需要用面向切面的思想，单独考虑增强的逻辑即可，代理类会在运行时由系统动态创建。代理模式是一种非常有用的设计模式，通过引入代理对象来控制对目标对象的访问，可以在不修改目标对象的前提下增加额外的功能，提高系统的灵活性和可扩展性。

具体实现中，通常会定义一个 Builder 类，它拥有产品类的所有属性，并定义一系列链式调用的 set 方法，用于修改产品类属性，最后通过 build() 方法集中校验并创建产品类对象。如果不在意对象是否可变和短暂无效状态，set 方式也是可以使用的，毕竟 Builder 中的重复代码和建造者对象也会造成一些损耗，具体还是要视需求复杂程度而定，在软件编码原则和需求契合度之间做折中。允许用户通过链式调用方法来逐步构建复杂对象，让复杂对象的构建与它的表示分离，即对象的表示和对象的构造过程解耦。

比如线程A通过了第一次检测，此时切换到线程B，由于 sInstance 还没被赋值，线程B也通过了第一次检测，此时无论哪个线程进入加锁代码，另一个线程都会等待锁释放后再进入加锁代码，这时就会导致重复初始化。单例的主要使用场景有两个，一是使用单例控制全局的资源访问，也就是用单例封装一些工具类，比如日志写入工具；这里用 Java 举例，会将实例初始化过程使用 synchronized 锁住，但加锁是非常损耗性能的操作，所以非常不推荐这样去写，更常见的写法应该是下面的双重检测。

抽象工厂模式使用抽象的接口来创建一系列相关或相互依赖的对象，而无需指定它们具体的类。这种方式主要用于创建一组相互依赖或关联的对象，而不需要指定它们具体的类。//抽象工厂//大文件解析器//再这里创建不同维度的产品类//小文件解析器//..省略//..省略//..省略//可根据具体业务，通过抽象工厂创建不同的产品类，无须关心实现类抽象工厂模式是工厂方法模式的升级版本，在有多个业务品种、业务分类时，通过抽象工厂模式产生需要的对象是一种非常好的解决方式。

利用已有对象来创建新对象的方式，就叫做原型模式。原型模式的核心是对象的拷贝，对象拷贝又分为浅拷贝和深拷贝，其中浅拷贝会共用引用类型对象，而深拷贝会创建新的引用对象。

状态机三要素：状态（State）、事件（Event）、动作（Action），事件驱动状态的流转，并触发动作的执行。实现状态及三种方式：分支判断法：优点：实现简单，适合状态较少的简单场景。缺点：大量 if-else 或 switch-case 代码，可读性和可扩展性差，不适合复杂逻辑。查表法：优点：代码中只需维护好状态流转表即可，代码比较直观，适合状态较多，且增加频繁的场景。