javascript数组怎么实现备忘录模式-js教程-PHP中文网

javascript数组备忘录模式的核心是通过发起人、备忘录和看管者三个角色实现状态的保存与恢复。1. 发起人（如versionedarray）负责创建和恢复状态，提供save()和restore()方法；2. 备忘录（arraymemento）存储数组的深拷贝快照，确保状态独立且不可变；3. 看管者（historymanager）管理备忘录的历史记录，支持undo和redo操作。实现时需使用深拷贝（如json.parse(json.stringify())或structuredclone()）以避免引用共享问题，防止状态污染。该模式适用于需要撤销/重做、版本控制等场景，但需注意深拷贝带来的性能开销和内存消耗，尤其在大规模数据或高频操作下可能成为瓶颈。替代方案包括不可变数据结构（如immer.js）、命令模式（按操作记录逆向执行）和事件溯源（基于事件重建状态），可根据具体需求选择更合适的方案。最终选择应权衡复杂性、性能和功能需求，确保状态管理既可靠又高效。

javascript数组怎么实现备忘录模式

JavaScript数组实现备忘录模式，核心在于创建一个机制，能够保存数组在特定时间点的状态（快照），并在需要时将其恢复到该状态。这通常通过设计模式中的“备忘录模式”来实现，即一个“发起人”对象（这里是我们的数组或其封装类）负责创建和恢复自身的状态，而一个“看管者”对象则负责存储这些状态的快照（备忘录），但不对其内容进行操作。

解决方案

要实现JavaScript数组的备忘录模式，我们需要定义三个主要角色：

发起人 (Originator)：这是我们想要保存和恢复其状态的对象，在这里就是我们的数组。它需要提供方法来创建其当前状态的备忘录，以及从备忘录中恢复状态。
备忘录 (Memento)：一个对象，用于存储发起人对象的内部状态。关键在于，这个备忘录应该是一个不可变的快照，并且对看管者来说是“黑箱”的，即看管者不应该直接访问或修改其内部数据。
看管者 (Caretaker)：负责存储和管理备忘录对象。它从发起人那里获取备忘录，并在需要时将其提供给发起人，但它从不检查备忘录的内容。

下面是一个具体的实现示例，我们创建一个

VersionedArray

登录后复制

类作为发起人，它内部封装了一个数组，并提供了保存和恢复状态的方法：

立即学习“Java免费学习笔记（深入）”；

// 备忘录类 (Memento)
class ArrayMemento {
    constructor(state) {
        // 存储数组的深拷贝状态，确保外部修改不影响快照
        this._state = JSON.parse(JSON.stringify(state)); 
    }

    getState() {
        return JSON.parse(JSON.stringify(this._state)); // 返回状态的深拷贝，防止外部修改备忘录内部状态
    }
}

// 发起人类 (Originator)
class VersionedArray {
    constructor(initialArray = []) {
        this.data = [...initialArray]; // 初始数据，浅拷贝即可
    }

    // 模拟数组操作
    push(...elements) {
        this.data.push(...elements);
        console.log(`Array after push: ${this.data}`);
    }

    pop() {
        const element = this.data.pop();
        console.log(`Array after pop: ${this.data}`);
        return element;
    }

    splice(start, deleteCount, ...items) {
        const removed = this.data.splice(start, deleteCount, ...items);
        console.log(`Array after splice: ${this.data}`);
        return removed;
    }

    // 创建备忘录（保存当前状态）
    save() {
        console.log("Saving current array state...");
        return new ArrayMemento(this.data);
    }

    // 从备忘录中恢复状态
    restore(memento) {
        if (memento instanceof ArrayMemento) {
            this.data = memento.getState();
            console.log(`Restored array state: ${this.data}`);
        } else {
            console.error("Invalid memento object provided.");
        }
    }

    getCurrentState() {
        return [...this.data]; // 返回当前状态的浅拷贝
    }
}

// 看管者类 (Caretaker)
class HistoryManager {
    constructor() {
        this.history = [];
        this.currentIndex = -1; // 用于undo/redo的索引
    }

    addMemento(memento) {
        // 如果在历史中间点添加新状态，则清除后续的“未来”状态
        if (this.currentIndex < this.history.length - 1) {
            this.history = this.history.slice(0, this.currentIndex + 1);
        }
        this.history.push(memento);
        this.currentIndex = this.history.length - 1;
        console.log("Memento added to history.");
    }

    undo() {
        if (this.currentIndex > 0) {
            this.currentIndex--;
            console.log("Undoing...");
            return this.history[this.currentIndex];
        }
        console.log("No more undo history.");
        return null;
    }

    redo() {
        if (this.currentIndex < this.history.length - 1) {
            this.currentIndex++;
            console.log("Redoing...");
            return this.history[this.currentIndex];
        }
        console.log("No more redo history.");
        return null;
    }

    getLatestMemento() {
        if (this.history.length > 0) {
            return this.history[this.history.length - 1];
        }
        return null;
    }
}

// 使用示例
const myVersionedArray = new VersionedArray(['apple', 'banana']);
const historyManager = new HistoryManager();

historyManager.addMemento(myVersionedArray.save()); // 初始状态

myVersionedArray.push('cherry');
historyManager.addMemento(myVersionedArray.save()); // 状态 1

myVersionedArray.splice(0, 1, 'date'); // 移除 apple，添加 date
historyManager.addMemento(myVersionedArray.save()); // 状态 2

myVersionedArray.pop(); // 移除 cherry
console.log(`Current array: ${myVersionedArray.getCurrentState()}`); // date, banana

// 尝试撤销
let mementoToRestore = historyManager.undo();
if (mementoToRestore) {
    myVersionedArray.restore(mementoToRestore); // 恢复到状态 2: date, banana, cherry
}
console.log(`After undo: ${myVersionedArray.getCurrentState()}`);

mementoToRestore = historyManager.undo();
if (mementoToRestore) {
    myVersionedArray.restore(mementoToRestore); // 恢复到状态 1: apple, banana, cherry
}
console.log(`After second undo: ${myVersionedArray.getCurrentState()}`);

// 尝试重做
mementoToRestore = historyManager.redo();
if (mementoToRestore) {
    myVersionedArray.restore(mementoToRestore); // 恢复到状态 2: date, banana, cherry
}
console.log(`After redo: ${myVersionedArray.getCurrentState()}`);

// 在中间点修改，会清除后续历史
myVersionedArray.push('elderberry');
historyManager.addMemento(myVersionedArray.save()); // 新的状态 3，清除重做历史

console.log(`Current array after new change: ${myVersionedArray.getCurrentState()}`);
mementoToRestore = historyManager.redo(); // 此时应该没有重做历史了

登录后复制

JavaScript数组备忘录模式：何时派上用场？

在我看来，为JavaScript数组引入备忘录模式，主要考量的是状态管理复杂性和用户体验需求。它不仅仅是简单地复制一个数组那么简单，更多的是提供一种结构化的方式来处理状态的保存与恢复。

最直观的场景，无疑是实现撤销（Undo）和重做（Redo）功能。想象一下，你在一个富文本编辑器里编辑内容，或者在一个图形设计工具里调整图层，每一步操作都可能改变底层的数据结构（比如一个包含所有图层信息的数组）。如果用户不小心删错了东西，或者想尝试不同的效果，一个可靠的撤销机制就显得至关重要。备忘录模式在这里就能发挥作用，每次关键操作后，我们都保存一个数组的快照，当用户点击“撤销”时，就从历史记录中取出上一个快照进行恢复。

此外，它也适用于版本控制或历史记录追踪。比如，在一个数据分析应用中，用户可能对同一个数据集进行多次转换和筛选。如果需要回溯到某个特定的中间状态进行对比，或者重新开始某个分支的分析，备忘录模式就能帮助我们有效地管理这些“历史版本”。它将数据的“时间切片”封装起来，使得我们能够方便地在不同时间点之间跳转，而不需要手动去管理复杂的克隆逻辑。

还有一点，备忘录模式能帮助我们解耦状态保存与业务逻辑。

VersionedArray

登录后复制

类（发起人）只负责知道如何保存和恢复自己的状态，而

HistoryManager

登录后复制

（看管者）只负责管理这些状态的集合，它们之间通过

ArrayMemento

登录后复制

这个媒介进行通信。这样一来，我们修改数组的业务逻辑时，不需要关心历史记录的存储方式；反之，调整历史记录的存储策略（比如限制历史记录数量，或者持久化到本地存储），也不影响数组本身的业务操作。这种分离，对于大型应用的代码维护和扩展性来说，简直是福音。

JavaScript数组状态快照：深拷贝与浅拷贝的抉择

在实现数组备忘录模式时，关于深拷贝（Deep Copy）和浅拷贝（Shallow Copy）的选择，这可不是个小问题，它直接关系到你保存的状态是否真的“独立”和“可靠”。我个人觉得，理解这个差异，是玩转JavaScript数据结构的关键一步。

简单来说：

浅拷贝：创建一个新数组，新数组的元素是原数组元素的引用。如果原数组里存的是基本类型（字符串、数字、布尔值），那没问题，新数组里就是这些基本值的副本。但如果原数组里存的是对象（包括其他数组），那么新数组里存的只是这些对象的“地址”，而不是它们内容的副本。这意味着，你通过新数组去修改这些对象，原数组里的对象也会跟着变，因为它们指向的是同一个内存地址。
深拷贝：创建一个新数组，并且递归地复制原数组中所有嵌套的对象和数组。这样，新数组和原数组之间就完全独立了，修改新数组的任何内容，都不会影响到原数组。

对于备忘录模式，我们的目标是保存一个独立且不可变的数组状态快照。这意味着，一旦快照被创建，后续对原数组的任何修改都不应该影响到这个快照，反之亦然。基于这个目标，绝大多数情况下，我们都需要进行深拷贝。

试想一下，如果你的数组

myArray = [{ id: 1, name: 'Item A' }, { id: 2, name: 'Item B' }]

登录后复制

，你用浅拷贝

myArray.slice()

登录后复制

保存了一个备忘录。然后你修改了

myArray[0].name = 'New Item A'

登录后复制

。这时，你之前保存的“快照”也会神奇地变成

[{ id: 1, name: 'New Item A' }, { id: 2, name: 'Item B' }]

登录后复制

。这显然不是我们想要的，因为快照的意义就是记录那一刻的真实状态，而不是一个会随原数据变化的“幽灵副本”。

实现深拷贝有几种常见方式：

```
JSON.parse(JSON.stringify(array))
```
登录后复制
：这是最简单粗暴，也是最常用的方法。它将数组序列化成JSON字符串，再反序列化回来。优点是简单快捷，不需要引入额外库。缺点也很明显：
- 不能处理函数、
```
undefined
```
  登录后复制
  登录后复制
  、
```
Symbol
```
  登录后复制
  登录后复制
  、
```
BigInt
```
  登录后复制
  类型的值（它们会在序列化过程中丢失）。
- 不能处理循环引用（会导致报错）。
- 不能处理
```
Date
```
  登录后复制
  登录后复制
  对象（会变成字符串）。
- 不能处理
```
RegExp
```
  登录后复制
  登录后复制
  对象。
- 性能对于非常大的、复杂的数组可能不够理想。
```
structuredClone()
```
登录后复制
登录后复制
API：这是现代浏览器提供的一个强大且安全的深拷贝方法。它能处理更多的数据类型（包括
```
Date
```
登录后复制
登录后复制
、
```
RegExp
```
登录后复制
登录后复制
、
```
Map
```
登录后复制
、
```
Set
```
登录后复制
、
```
ArrayBuffer
```
登录后复制
等），也能处理循环引用。缺点是兼容性（旧浏览器可能不支持），以及仍然不能克隆函数。
自定义递归深拷贝函数：如果你需要处理
```
JSON.parse(JSON.stringify())
```
登录后复制
登录后复制
无法处理的特定类型（如函数），或者需要更细粒度的控制，就需要手写一个递归函数。这会增加代码复杂性，但提供了最大的灵活性。
第三方库：像 Lodash 的
```
_.cloneDeep()
```
登录后复制
，或者
```
immer.js
```
登录后复制
登录后复制
(虽然
```
immer
```
登录后复制
更多是用于简化不可变数据操作，而不是直接深拷贝)。这些库通常提供了健壮且经过优化的深拷贝实现。

在我们的示例中，我选择了

JSON.parse(JSON.stringify(state))

登录后复制

，因为它对于大多数只包含可序列化数据的数组场景来说，已经足够简单和有效了。但如果你处理的数组包含函数、日期对象、Set/Map 等非纯数据结构，那么就得考虑

structuredClone()

登录后复制

或自定义方案了。性能也是一个考虑点，频繁地对一个包含成千上万个对象的数组进行深拷贝，可能会带来明显的性能开销。

实现JavaScript数组备忘录模式的常见陷阱与替代方案

在实践中，尽管备忘录模式提供了一种优雅的状态管理方案，但它并非没有自己的“坑”，同时，也有一些其他模式或库可以作为替代，甚至在某些场景下表现得更好。

常见陷阱：

性能与内存消耗：这几乎是深拷贝的“原罪”。如果你的数组非常大，或者状态变更非常频繁，每次保存状态都进行一次完整的深拷贝，会消耗大量的CPU时间和内存。想象一个包含几万个复杂对象的数组，每秒钟变化好几次，那么你的历史记录可能会迅速膨胀，导致应用卡顿甚至崩溃。这就像你拍照留念，但每次拍照都把整个世界复制一份，很快硬盘就满了。
非可序列化数据的问题：前面提到了，
```
JSON.parse(JSON.stringify())
```
登录后复制
登录后复制
这种深拷贝方式对函数、
```
undefined
```
登录后复制
登录后复制
、
```
Symbol
```
登录后复制
登录后复制
、DOM节点、循环引用等数据类型是无能为力的。如果你的数组里包含了这些“特殊”的数据，那么简单的 JSON 转换就会导致数据丢失或错误。你需要更复杂的深拷贝方案，或者在设计之初就避免在数组中存储这类数据。
过度设计：对于非常简单的数组操作，比如你只是想撤销一个
```
push
```
登录后复制
或
```
pop
```
登录后复制
登录后复制
，可能直接维护一个操作日志，或者简单地克隆数组然后
```
pop
```
登录后复制
登录后复制
掉最后一个元素，比引入完整的备忘录模式要轻量得多。备忘录模式的优势在于其结构化和解耦，但如果问题本身很简单，这种“模式化”的解决方案反而可能显得过于臃肿。
历史记录管理：看管者需要管理历史记录，比如限制历史记录的数量（只保留最近N个状态），或者清除“未来”的历史（当在历史中间点进行新的操作时）。这些逻辑需要精心设计，否则用户体验可能会很糟糕，或者内存持续增长。

替代方案：

不可变数据结构 (Immutable Data Structures) / Immutability 库：这是现代前端框架（如 React/Redux 生态）中非常流行的一种模式。其核心思想是：数据一旦创建就不能被修改。每次需要“修改”数据时，实际上是创建一个新的、修改后的数据副本。
- 优点：天生支持历史记录和时间旅行调试。因为每次操作都生成新对象，旧对象自然就成了历史快照。比较新旧状态也变得高效（通过引用比较）。
- 库示例：
```
immer.js
```
  登录后复制
  登录后复制
  允许你用“可变”的方式操作数据，但它会在底层帮你生成不可变的新状态。
```
Immutable.js
```
  登录后复制
  提供了完全不可变的数据结构，但需要学习其特定的API。
- 适用场景：复杂的状态管理，特别是需要频繁撤销/重做，或者与 Redux 等状态管理库结合使用时。
命令模式 (Command Pattern)：这种模式关注的是“操作”本身，而不是数据的快照。你可以将每次对数组的修改封装成一个“命令”对象，这个命令对象知道如何执行操作，也知道如何撤销操作。
- 优点：非常适合撤销/重做，因为每个命令都包含了正向和反向操作的逻辑。内存占用通常比备忘录模式小，因为它不存储整个数据的副本，只存储操作本身。
- 缺点：每个可撤销的操作都需要编写对应的命令类或函数。如果操作种类很多，代码量可能会增加。
- 适用场景：操作类型固定且可逆的场景，比如图形编辑器的绘制、移动、删除等操作。
事件溯源 (Event Sourcing)：这是一种更宏大的架构模式。它不保存数据的当前状态，而是保存所有导致状态变化的“事件”序列。当你需要某个时间点的状态时，就从头开始“回放”所有事件，直到那个时间点。
- 优点：数据的完整历史被保留，可以随时重建任何时间点的状态。非常适合审计、调试和数据分析。
- 缺点：实现复杂，需要一个事件存储系统。重建状态可能需要消耗大量计算资源，特别是事件很多的时候。
- 适用场景：对数据历史记录要求极高，且需要从历史事件中派生出不同视图的复杂系统。