🌈 个人主页：danci_
🔥 系列专栏：《设计模式》
💪🏻 制定明确可量化的目标，并且坚持默默的做事。
🚀 转载自：https://blog.csdn.net/danci_/article/details/136386929
备忘录模式揭秘-实现时光回溯、一键还原、后悔药和穿越时空隧道
文章目录
一、案例场景🔍
1.1 经典的运用场景
备忘录模式在不同场合下都有着广泛的应用场景。通过合理利用备忘录模式的功能和特点，我们可以更好地管理时间、提高工作效率、提升学习效果等。让我们充分发挥备忘录文章的优势吧！以下是备忘录模式个人生活、工作和 应用等场景中的经典应用：👇
-
日程管理（个人生活）:
假设你是一位忙碌的职场人，每天需要处理多项任务和活动。你可以通过备忘录文章来规划你的日程。在备忘录中，你可以列出每天的任务清单、预计完成时间、重要程度等，这样你就能一目了然地知道应该先做什么，后做什么，从而更有效地管理你的时间。 -
会议纪要（工作）:
在团队会议中，你可能会讨论许多重要的议题和决策。为了确保会议内容得到准确传达和执行，你可以在备忘录文章中记录会议纪要。这包括会议的时间、地点、参与者、讨论的主题、做出的决策等。通过备忘录文章，你可以轻松地回顾会议内容，确保工作的顺利进行。 -
学习计划（学习）:
为了提高学习效率，你可以制定详细的学习计划并记录在备忘录文章中。这包括每天的学习任务、复习计划、目标等。通过定期更新和回顾备忘录文章中的内容，你可以更好地掌握自己的学习进度和效果，从而及时调整学习策略和方法。下面我们来实现日程管理场景 📄✏️。
1.2 一坨坨代码实现😻
可以创建一个简单的ScheduleManager类来管理日程。这个类可以包含添加任务、列出任务、标记任务为完成等功能。下面是一个简单的实现示例：👇
import java.util.ArrayList;
import java.util.List;
class Task {
private String description;
private boolean isCompleted;
public Task(String description) {
this.description = description;
this.isCompleted = false;
}
public String getDescription() {
return description;
}
public boolean isCompleted() {
return isCompleted;
}
public void complete() {
isCompleted = true;
}
@Override
public String toString() {
return "Task{" +
"description='" + description + '\'' +
", isCompleted=" + isCompleted +
'}';
}
}
class ScheduleManager {
private List<Task> tasks;
public ScheduleManager() {
tasks = new ArrayList<>();
}
public void addTask(String description) {
Task newTask = new Task(description);
tasks.add(newTask);
System.out.println("Task added: " + newTask);
}
public void listTasks() {
System.out.println("Current tasks:");
for (Task task : tasks) {
if (task.isCompleted()) {
System.out.println("(Completed) " + task.getDescription());
} else {
System.out.println(task.getDescription());
}
}
}
public void completeTask(int index) {
if (index >= 0 && index < tasks.size()) {
Task taskToComplete = tasks.get(index);
taskToComplete.complete();
System.out.println("Task completed: " + taskToComplete.getDescription());
} else {
System.out.println("Invalid task index.");
}
}
}
public class Main {
public static void main(String[] args) {
ScheduleManager manager = new ScheduleManager();
// 添加任务
manager.addTask("Go to the gym");
manager.addTask("Write a blog post");
manager.addTask("Call mom");
// 列出任务
manager.listTasks();
// 完成一个任务
manager.completeTask(1); // 假设我们完成了第二个任务 "Write a blog post"
// 再次列出任务，查看哪些已完成
manager.listTasks();
}
}
在这个示例中，我们定义了一个Task类来表示单个任务，其中包含任务的描述和是否已完成的状态。ScheduleManager类负责管理这些任务，提供了添加任务、列出任务和完成任务的方法。
在main方法中，我们创建了一个ScheduleManager实例，并通过它来添加、列出和完成任务。这是一个非常简单的实现，没有使用任何设计模式，并且编码逻辑清晰。当然，在实际应用中，你可能需要添加更多的功能，比如任务的优先级、截止日期等。但这个示例提供了一个良好的起点。
虽然上述实现没有使用设计模式，但也体现出了如下优点：👇
- 简单性：
✨代码逻辑清晰，易于理解。没有使用复杂的设计模式或高级特性，使得代码易于维护。 - 封装性：
✨Task 类封装了任务的基本属性（描述和完成状态），并通过方法提供了对这些属性的访问和修改。这有助于保持数据的完整性和一致性。 - 可扩展性：
✨虽然当前实现很简单，但它为未来的扩展留下了空间。例如，可以在 Task 类中添加更多属性（如优先级、截止日期等），或在 ScheduleManager 类中添加更多功能（如任务排序、过滤等）。 - 控制台输出：
✨通过直接在方法中打印输出，这个简单的实现提供了即时的反馈，这在开发原型或小型应用程序时很有用。 - 列表存储：
✨使用 ArrayList 存储任务，这提供了一种动态的方式来添加和移除任务。列表数据结构也支持按索引访问元素，这在完成特定任务时很有用。 - 类型安全：
✨使用了泛型集合类 ArrayList 来存储任务，这确保了集合中只能包含 Task 类型的对象，增强了类型安全。
这个实现也有一些可以改进的地方：
- 索引访问：
✨使用索引来完成任务可能不是很直观或用户友好。在实际应用中，可能会更倾向于使用任务ID、名称或其他唯一标识符来完成任务。 - 控制台耦合：
✨直接在 ScheduleManager 类中使用 System.out.println 进行输出，这导致了类与控制台的紧密耦合。更好的做法是使用日志记录或观察者模式来解耦输出逻辑。 - 缺乏持久化：
✨当前实现中，任务数据仅存储在内存中，程序结束时数据会丢失。在实际应用中，可能需要将数据持久化到数据库或文件中。 - 缺乏异常处理：
✨例如，当尝试完成一个不存在的任务索引时，只是简单地打印一条错误消息。在实际应用中，可能需要更详细的错误处理或异常抛出机制。
上面的实现作为一个简单的示例是有效的，但在构建更复杂、健壮的应用程序时，还需要考虑更多的设计和实现细节。
1.3 痛点
然而，没有复杂的设计下体现上述优点的同时也伴随着一些潜在的缺点，这些缺点可能在更复杂或更大规模的应用中变得更加显著。以下是一些主要的缺点：👇
缺点（问题）下面逐一分析：
- 索引使用不直观：
😉 使用整数索引来标识和完成任务对于用户来说可能不够直观。在真实世界的应用中，通常使用更有意义的标识符，如任务ID或任务名称。 - 控制台输出与业务逻辑耦合：
😉 直接在业务逻辑类（如ScheduleManager）中使用System.out.println进行输出，这导致了业务逻辑与输出表示的紧密耦合。更好的做法是将业务逻辑与表示逻辑分离，例如通过使用观察者模式或依赖注入来解耦。 - 缺乏持久化机制：
😉 当前的任务管理仅在内存中有效。一旦程序结束，所有任务数据都会丢失。对于长期存储和检索任务数据，需要实现持久化机制，如将数据保存到数据库或文件系统中。 - 错误处理不足：
😉 当前的实现对于错误情况（如无效的索引）仅打印一条简单的错误消息。在实际应用中，应该提供更健壮的错误处理机制，可能包括抛出异常、返回错误代码或使用专门的错误处理框架。 - 缺乏灵活性：
😉当前实现不支持对任务的排序、过滤或分组等高级功能。这些功能在更复杂的日程管理系统中可能是必需的。 - 线程不安全：
😉 如果多个线程同时访问和修改ScheduleManager中的任务列表，可能会导致数据不一致。当前的实现没有考虑线程安全性。
违反的设计原则（问题）下面逐一分析：👇
- 单一职责原则（Single Responsibility Principle, SRP）：
🚀 根据这一原则，每个类应该只有一个引起变化的原因。在上述实现中，ScheduleManager 类同时负责了管理任务的添加、列出、完成以及直接与控制台交互进行输出。这导致了类的职责不够单一，特别是与控制台输出的耦合违背了这一原则。 - 开闭原则（Open-Closed Principle, OCP）：
🚀 软件实体应该对扩展开放，对修改关闭。这意味着在不修改现有代码的情况下，应该能够添加新功能。在上述实现中，如果需要添加新的功能，如任务排序或按条件过滤任务，可能需要直接修改ScheduleManager类，这违背了开闭原则。 - 依赖倒置原则（Dependency Inversion Principle, DIP）：
🚀 高层模块不应该依赖于低层模块，它们都应该依赖于抽象。在上述实现中，ScheduleManager 直接依赖于具体的Task实现，并没有使用抽象或接口来定义任务，这使得将来更换任务实现或进行单元测试时更加困难。 - 接口隔离原则（Interface Segregation Principle, ISP）：
🚀 客户端不应该依赖于它不需要的接口。在上述代码中，虽然没有显式定义接口，但如果ScheduleManager的方法被不同的客户端以不同的方式使用（例如，有些客户端只需要添加任务而不需要列出或完成任务），则可能会违背这一原则。
二、解决方案🚀
2.1 定义
| 保存对象内部状态的快照，以便在需要时恢复对象至某一历史状态。 |
2.2 案例分析🧐
关键因素分析：
- 关键因素可能包括对象状态的保存、恢复和管理的需求。
例如，用户可能需要随时将任务对象恢复到先前的某个状态，这就要求系统能够记录并保存对象的状态，以便在需要时进行恢复。此外，对象状态的复杂性也可能是一个关键因素，因为复杂的状态可能需要更精细的管理和恢复机制。
为何适合使用备忘录模式分析：
- 备忘录模式提供了一种在不破坏对象封装性的前提下捕获对象内部状态，并在以后将该对象恢复到原先状态的方式。
备忘录模式将状态的保存和恢复逻辑分离开来，使得这些逻辑与对象本身的业务逻辑无关，从而提高了代码的可维护性和可扩展性。 - 如果任务对象的状态需要在执行过程中被保存，并在以后的某个时间点被恢复，那么备忘录模式将是一个很好的选择。
通过使用备忘录模式，我们可以将任务对象的状态保存到备忘录对象中，并在需要时从备忘录对象中恢复任务对象的状态。
使用备忘录实现的注意事项：👇
- 管理备忘录的生命周期：
备忘录对象创建后需要在合适的时候被销毁，以避免内存泄漏。系统需要主动管理备忘录对象的生命周期，确保在不需要时及时删除其引用。 - 考虑备忘录的性能开销：
频繁地创建和销毁备忘录对象可能会带来性能开销，特别是在处理大量数据或高频操作时。因此，在使用备忘录模式时需要权衡其带来的好处和性能开销。 - 保护备忘录对象的安全性：
备忘录对象可能包含敏感信息，因此需要确保只有授权的代码才能访问和修改备忘录对象。此外，还需要防止备忘录对象被意外修改或破坏。 - 注意状态的完整性和一致性：
在保存和恢复对象状态时，需要确保状态的完整性和一致性。这意味着在恢复状态时，对象应该能够恢复到一个一致且可用的状态，而不是一个无效或错误的状态。
何时选用备忘录模式来实现：👇
- 当需要保存一个对象在某一时刻的状态，并在以后能够恢复该状态时，可以使用备忘录模式。这通常用于实现撤销操作、历史记录或版本控制等功能。
- 当对象的状态变化非常复杂或难以预测时，备忘录模式可以提供一种灵活且可靠的方式来管理对象的状态。通过保存对象的状态到备忘录对象中，可以在需要时随时恢复对象到先前的状态，而无需关心状态变化的具体细节。
- 当需要保护对象状态的安全性时，备忘录模式也是一种很好的选择。通过将对象的状态封装在备忘录对象中，并限制对备忘录对象的访问权限，可以确保对象的状态不会被外部代码意外修改或破坏。
2.3 备忘录模式结构图及说明
- 发起人（Originator）：
· 记录当前时刻的内部状态信息。
· 提供创建备忘录和恢复备忘录数据的功能。
· 实现其他业务功能，并可以访问备忘录里的所有信息。
· 在备忘录模式中，发起人负责创建一个备忘录来存储自己当前的内部状态，同时它也可以使用备忘录来恢复其内部状态到之前保存的状态。 - 备忘录（Memento）：
· 负责存储发起人的内部状态。
· 在需要的时候提供这些内部状态给发起人，以供恢复状态。
· 备忘录可以根据需要决定存储发起人的哪些内部状态，并且防止发起人以外的对象访问备忘录。
· 备忘录通常提供两个接口：窄接口（Caretaker可见）和宽接口（Originator可见）。宽接口允许发起人访问备忘录中的所有数据。 - 管理者（Caretaker）：
· 负责保存备忘录，但不能对备忘录的内容进行操作或访问。
· 只负责将备忘录传递给其他对象，如发起人。
· 管理者对备忘录进行管理，提供保存与获取备忘录的功能，但它对备忘录内部存储的状态信息一无所知。
2.4 使用备忘务模式重构示例
重构步骤
为了重构上述代码并解决其缺点，我们可以使用备忘录模式来重构代码。可以考虑以下步骤：👇
- 引入接口和抽象类以增加灵活性和可扩展性。
- 使用备忘录模式来保存和恢复任务的状态。
- 分离控制台输出和业务逻辑。
- 考虑持久化存储。
下面是一个简化的重构示例，其中应用了备忘录模式来解决任务状态的保存和恢复问题：👇
- 定义任务接口
public interface Task {
String getDescription();
void setCompleted(boolean completed);
boolean isCompleted();
// 为备忘录模式添加的方法
TaskMemento createMemento();
void restoreFromMemento(TaskMemento memento);
}
- 具体的任务类实现任务接口
public class ConcreteTask implements Task {
private String description;
private boolean completed;
public ConcreteTask(String description) {
this.description = description;
this.completed = false;
}
@Override
public String getDescription() {
return description;
}
@Override
public void setCompleted(boolean completed) {
this.completed = completed;
}
@Override
public boolean isCompleted() {
return completed;
}
// 实现创建备忘录的方法
@Override
public TaskMemento createMemento() {
return new TaskMemento(description, completed);
}
// 实现从备忘录恢复状态的方法
@Override
public void restoreFromMemento(TaskMemento memento) {
this.description = memento.getDescription();
this.completed = memento.isCompleted();
}
}
- 定义备忘录类来保存任务的状态
public class TaskMemento {
private String description;
private boolean completed;
public TaskMemento(String description, boolean completed) {
this.description = description;
this.completed = completed;
}
public String getDescription() {
return description;
}
public boolean isCompleted() {
return completed;
}
}
- 定义任务管理器类，负责任务的添加、列出、完成以及保存状态等操作
public class TaskManager {
private List<Task> tasks = new ArrayList<>();
// 可以考虑添加用于保存备忘录的列表或其他持久化机制
private List<TaskMemento> taskMementos = new ArrayList<>();
public void addTask(Task task) {
tasks.add(task);
}
public void listTasks() {
for (Task task : tasks) {
System.out.println(task.getDescription() + " - " + (task.isCompleted() ? "Completed" : "Not Completed"));
}
}
public void completeTask(int index) {
if (index >= 0 && index < tasks.size()) {
Task task = tasks.get(index);
task.setCompleted(true);
// 保存任务状态到备忘录中
TaskMemento memento = task.createMemento();
taskMementos.add(memento);
} else {
System.out.println("Invalid task index.");
}
}
// 添加一个新方法来恢复任务到之前的状态（如果需要的话）
public void restoreTask(int mementoIndex) {
if (mementoIndex >= 0 && mementoIndex < taskMementos.size()) {
TaskMemento memento = taskMementos.get(mementoIndex);
// 假设我们想要恢复最后一个任务的状态（这里简化处理）
Task taskToRestore = tasks.get(tasks.size() - 1);
taskToRestore.restoreFromMemento(memento);
} else {
System.out.println("Invalid memento index.");
}
}
}
- 控制台视图类，负责与用户交互和显示信息（与控制台输出解耦）
public class ConsoleView {
private TaskManager taskManager;
public ConsoleView(TaskManager taskManager) {
this.taskManager = taskManager;
}
public void addTask(String description) {
Task task = new ConcreteTask(description);
taskManager.addTask(task);
}
public void listTasks() {
taskManager.listTasks();
}
public void completeTask(int index) {
taskManager.completeTask(index);
}
// 添加恢复任务的方法到控制台视图中（如果需要的话）
public void restoreTask(int mementoIndex) {
taskManager.restoreTask(mementoIndex);
}
}
- 主程序入口（示例）
public class Main {
public static void main(String[] args) {
TaskManager taskManager = new TaskManager();
ConsoleView consoleView = new ConsoleView(taskManager);
consoleView.addTask("Prepare presentation");
consoleView.addTask("Write report");
consoleView.listTasks(); // 列出所有任务
consoleView.completeTask(0); // 完成第一个任务，同时保存其状态到备忘录中
consoleView.listTasks(); // 列出所有任务，显示第一个已完成
// ... 这里可以添加更多操作，如添加新任务、完成其他任务等
// 如果需要的话，可以从备忘录中恢复任务状态
// consoleView.restoreTask(相应的备忘录索引);
}
}
在这个重构后的代码中，我们引入了Task接口和ConcreteTask实现类来增加灵活性。TaskManager类负责管理任务，并且现在包含了用于保存任务状态备忘录的列表。我们还添加了ConsoleView类来分离控制台输出和业务逻辑。需要注意的是，这里的备忘录模式实现是为了展示如何保存和恢复任务状态，并没有完全遵循备忘录模式的所有最佳实践（例如，通常会有一个发起人来负责创建和恢复备忘录，以及一个管理者来负责存储备忘录）。此外，为了简化示例，持久化存储的实现也没有包含在内。在实际应用中，可以考虑使用数据库或文件系统来实现任务数据的持久化存储。
2.5 重构后解决的问题👍
优点
上述实现解决了以下已知缺点：👇
- 增加灵活性和可扩展性：
✨ 通过引入接口（Task）和抽象类，我们可以更容易地添加新的任务类型或修改现有任务的行为，而不需要更改使用它们的代码。这符合“开闭原则”，即对扩展开放，对修改关闭。 - 任务状态的保存和恢复：
✨ 通过实现备忘录模式，我们现在可以保存任务的状态（TaskMemento）并在以后恢复它。这对于撤销操作、历史记录或版本控制等功能非常有用。 - 分离关注点：
✨ 通过将控制台输出和业务逻辑分离到不同的类中（ConsoleView和TaskManager），我们提高了代码的可维护性和可读性。ConsoleView负责处理用户输入和显示信息，而TaskManager则专注于管理任务的状态和行为。 - 为持久化存储做准备：
✨ 虽然上述示例中没有直接实现持久化存储，但通过将任务状态保存在备忘录列表中，我们已经为将来的持久化存储打下了基础。这个列表可以很容易地替换为数据库或文件系统的实现。 - 更好的封装性：
✨ 备忘录模式允许我们在不破坏对象封装性的情况下捕获和恢复其内部状态。这意味着我们可以隐藏任务的内部实现细节，同时仍然能够保存和恢复其状态。
注：上述实现并没有完全解决所有可能的缺点或问题。例如，它并没有处理并发访问或线程安全的问题，也没有实现完整的错误处理或用户输入验证。这些功能在实际应用中可能是必要的，但需要根据具体的需求和上下文来设计和实现。
遵循的设计原则
上述示例使用备忘录模式重构后的代码遵循了以下设计原则：👇
-
单一职责原则（SRP）：
✈️ 每个类只负责一项功能。例如，TaskManager 类负责管理任务，而 ConsoleView 类负责处理用户输入和显示信息。这使得代码更易于理解、维护和测试。 -
开闭原则（OCP）：
✈️ 软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。在上述实现中，通过引入接口和抽象类，可以更容易地添加新的任务类型或修改现有任务的行为，而不需要更改使用它们的代码。 -
里氏替换原则（LSP）：
✈️ 子类必须能够替换其父类，并且不影响程序的行为。虽然上述实现中没有明确显示子类替换父类的情况，但如果我们有一个基于Task接口的具体任务类，我们应该能够将其替换为任何其他实现了相同接口的任务类，而不会破坏程序的功能。 -
接口隔离原则（ISP）：
✈️ 客户端不应该依赖于它不使用的接口。在上述实现中，TaskManager 和 ConsoleView 只依赖于它们真正需要的接口，而不是整个系统的所有接口。这有助于减少类之间的耦合度。 -
依赖倒置原则（DIP）：
✈️ 高层模块不应该依赖于低层模块，它们都应该依赖于抽象。在上述实现中，通过使用接口（如 Task）和抽象类，高层模块（如 TaskManager）与低层模块（具体的任务实现）之间的依赖被最小化。这使得代码更加灵活和可重用。还可能遵循了其他设计原则，如：
-
迪米特法则（LoD）或最少知识原则：
✈️ 一个对象应该对其他对象保持最少的了解。在上述实现中，各个类之间通过接口进行交互，而不是直接操作其他类的内部状态或方法。这有助于降低类之间的耦合度。 -
合成复用原则：
✈️ 尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的。在上述实现中，可以看到通过组合不同的对象（如 TaskManager 和 ConsoleView）来实现整体功能，而不是通过继承来扩展功能。这有助于提高代码的灵活性和可维护性。
缺点
任何实现都不可能完美，上述实现同样可能存在一些缺点或潜在的改进点。以下是一些可能存在的缺点：👇
- 缺乏异常处理：
💡 在上述实现中，可能没有明显的异常处理机制。这意味着如果发生错误（如无效的用户输入、任务执行失败等），程序可能会崩溃或产生不可预测的行为。为了增加健壮性，应该添加适当的异常处理代码。 - 用户输入验证不足：
💡 ConsoleView 类在处理用户输入时可能没有进行充分的验证。这可能导致非法或意外的输入被接受，从而影响程序的正常运行。应该对用户输入进行严格的验证和清洗。 - 硬编码和魔数：
💡 如果实现中包含了硬编码的值（如固定的任务类型、状态代码等），那么这些值在未来的修改中可能会变得非常困难。应该使用常量、枚举或配置文件来管理这些值，以便更容易地进行更改。 - 线程安全性问题：
💡 如果多个线程同时访问和修改共享资源（如任务列表），可能会发生数据不一致的问题。上述实现可能没有考虑线程安全性，这在多线程环境中是一个潜在的问题。可以通过同步机制（如锁）来解决这个问题。 - 可扩展性的局限性：
💡 虽然实现中使用了接口和抽象类来增加灵活性，但在某些方面可能仍然存在可扩展性的局限性。例如，如果需要添加新的视图类型（不仅仅是控制台视图），则可能需要修改现有的代码结构。可以通过使用更高级的设计模式（如工厂模式、策略模式等）来进一步提高可扩展性。 - 缺乏日志记录和监控：
💡 在实际应用中，日志记录和监控是非常重要的功能，可以帮助开发人员诊断和解决问题。上述实现中可能没有包含这些功能，这可能会使得问题难以追踪和解决。 - 性能考虑：
💡 如果任务列表变得非常大，或者任务的执行变得非常频繁，那么性能可能会成为一个问题。在这种情况下，可能需要考虑使用更高效的数据结构或算法来优化性能。
注：这些缺点并不一定都存在于上述实现中，而是根据一般的经验和最佳实践提出的潜在问题点。具体的缺点取决于实现的细节和使用场景。因此，在评估一个实现的优缺点时，应该结合具体的上下文和需求来进行分析。
转载文章只截取部分内容。
更多（或三连）请跳转原文地址：https://blog.csdn.net/danci_/article/details/136386929
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
