?🌈 個人主頁：danci_
🔥 系列專欄：《設計模式》
💪🏻 制定明確可量化的目標，并且堅持默默的做事。

---

一、案例場景🔍

1.1 經典的運用場景

????備忘錄模式在不同場合下都有著廣泛的應用場景。通過合理利用備忘錄模式的功能和特點，我們可以更好地管理時間、提高工作效率、提升學習效果等。讓我們充分發揮備忘錄文章的優勢吧！以下是備忘錄模式個人生活、工作和 應用等場景中的經典應用：👇

1. 日程管理（個人生活）:
   假設你是一位忙碌的職場人，每天需要處理多項任務和活動。你可以通過備忘錄文章來規劃你的日程。在備忘錄中，你可以列出每天的任務清單、預計完成時間、重要程度等，這樣你就能一目了然地知道應該先做什么，后做什么，從而更有效地管理你的時間。

2. 會議紀要（工作）:
   在團隊會議中，你可能會討論許多重要的議題和決策。為了確保會議內容得到準確傳達和執行，你可以在備忘錄文章中記錄會議紀要。這包括會議的時間、地點、參與者、討論的主題、做出的決策等。通過備忘錄文章，你可以輕松地回顧會議內容，確保工作的順利進行。

3. 學習計劃（學習）:
   為了提高學習效率，你可以制定詳細的學習計劃并記錄在備忘錄文章中。這包括每天的學習任務、復習計劃、目標等。通過定期更新和回顧備忘錄文章中的內容，你可以更好地掌握自己的學習進度和效果，從而及時調整學習策略和方法。

   ????下面我們來實現日程管理場景 📄??。

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實例，并通過它來添加、列出和完成任務。這是一個非常簡單的實現，沒有使用任何設計模式，并且編碼邏輯清晰。當然，在實際應用中，你可能需要添加更多的功能，比如任務的優先級、截止日期等。但這個示例提供了一個良好的起點。

????雖然上述實現沒有使用設計模式，但也體現出了如下優點：👇

1. 簡單性：
   ?代碼邏輯清晰，易于理解。沒有使用復雜的設計模式或高級特性，使得代碼易于維護。
2. 封裝性：
   ?Task 類封裝了任務的基本屬性（描述和完成狀態），并通過方法提供了對這些屬性的訪問和修改。這有助于保持數據的完整性和一致性。
3. 可擴展性：
   ?雖然當前實現很簡單，但它為未來的擴展留下了空間。例如，可以在 Task 類中添加更多屬性（如優先級、截止日期等），或在 ScheduleManager 類中添加更多功能（如任務排序、過濾等）。
4. 控制臺輸出：
   ?通過直接在方法中打印輸出，這個簡單的實現提供了即時的反饋，這在開發原型或小型應用程序時很有用。
5. 列表存儲：
   ?使用 ArrayList 存儲任務，這提供了一種動態的方式來添加和移除任務。列表數據結構也支持按索引訪問元素，這在完成特定任務時很有用。
6. 類型安全：
   ?使用了泛型集合類 ArrayList 來存儲任務，這確保了集合中只能包含 Task 類型的對象，增強了類型安全。

????這個實現也有一些可以改進的地方：

1. 索引訪問：
   ?使用索引來完成任務可能不是很直觀或用戶友好。在實際應用中，可能會更傾向于使用任務ID、名稱或其他唯一標識符來完成任務。
2. 控制臺耦合：
   ?直接在 ScheduleManager 類中使用 System.out.println 進行輸出，這導致了類與控制臺的緊密耦合。更好的做法是使用日志記錄或觀察者模式來解耦輸出邏輯。
3. 缺乏持久化：
   ?當前實現中，任務數據僅存儲在內存中，程序結束時數據會丟失。在實際應用中，可能需要將數據持久化到數據庫或文件中。
4. 缺乏異常處理：
   ?例如，當嘗試完成一個不存在的任務索引時，只是簡單地打印一條錯誤消息。在實際應用中，可能需要更詳細的錯誤處理或異常拋出機制。

????上面的實現作為一個簡單的示例是有效的，但在構建更復雜、健壯的應用程序時，還需要考慮更多的設計和實現細節。

1.3 痛點

????然而，沒有復雜的設計下體現上述優點的同時也伴隨著一些潛在的缺點，這些缺點可能在更復雜或更大規模的應用中變得更加顯著。以下是一些主要的缺點：👇
????缺點（問題）下面逐一分析：

1. 索引使用不直觀：
   😉 使用整數索引來標識和完成任務對于用戶來說可能不夠直觀。在真實世界的應用中，通常使用更有意義的標識符，如任務ID或任務名稱。
2. 控制臺輸出與業務邏輯耦合：
   😉 直接在業務邏輯類（如ScheduleManager）中使用System.out.println進行輸出，這導致了業務邏輯與輸出表示的緊密耦合。更好的做法是將業務邏輯與表示邏輯分離，例如通過使用觀察者模式或依賴注入來解耦。
3. 缺乏持久化機制：
   😉 當前的任務管理僅在內存中有效。一旦程序結束，所有任務數據都會丟失。對于長期存儲和檢索任務數據，需要實現持久化機制，如將數據保存到數據庫或文件系統中。
4. 錯誤處理不足：
   😉 當前的實現對于錯誤情況（如無效的索引）僅打印一條簡單的錯誤消息。在實際應用中，應該提供更健壯的錯誤處理機制，可能包括拋出異常、返回錯誤代碼或使用專門的錯誤處理框架。
5. 缺乏靈活性：
   😉當前實現不支持對任務的排序、過濾或分組等高級功能。這些功能在更復雜的日程管理系統中可能是必需的。
6. 線程不安全：
   😉 如果多個線程同時訪問和修改ScheduleManager中的任務列表，可能會導致數據不一致。當前的實現沒有考慮線程安全性。

????違反的設計原則（問題）下面逐一分析：👇

1. 單一職責原則（Single Responsibility Principle, SRP）：
   🚀 根據這一原則，每個類應該只有一個引起變化的原因。在上述實現中，ScheduleManager 類同時負責了管理任務的添加、列出、完成以及直接與控制臺交互進行輸出。這導致了類的職責不夠單一，特別是與控制臺輸出的耦合違背了這一原則。
2. 開閉原則（Open-Closed Principle, OCP）：
   🚀 軟件實體應該對擴展開放，對修改關閉。這意味著在不修改現有代碼的情況下，應該能夠添加新功能。在上述實現中，如果需要添加新的功能，如任務排序或按條件過濾任務，可能需要直接修改ScheduleManager類，這違背了開閉原則。
3. 依賴倒置原則（Dependency Inversion Principle, DIP）：
   🚀 高層模塊不應該依賴于低層模塊，它們都應該依賴于抽象。在上述實現中，ScheduleManager 直接依賴于具體的Task實現，并沒有使用抽象或接口來定義任務，這使得將來更換任務實現或進行單元測試時更加困難。
4. 接口隔離原則（Interface Segregation Principle, ISP）：
   🚀 客戶端不應該依賴于它不需要的接口。在上述代碼中，雖然沒有顯式定義接口，但如果ScheduleManager的方法被不同的客戶端以不同的方式使用（例如，有些客戶端只需要添加任務而不需要列出或完成任務），則可能會違背這一原則。

二、解決方案🚀

2.1 定義

保存對象內部狀態的快照，以便在需要時恢復對象至某一歷史狀態。

2.2 案例分析🧐

????關鍵因素分析：

• 關鍵因素可能包括對象狀態的保存、恢復和管理的需求。
  例如，用戶可能需要隨時將任務對象恢復到先前的某個狀態，這就要求系統能夠記錄并保存對象的狀態，以便在需要時進行恢復。此外，對象狀態的復雜性也可能是一個關鍵因素，因為復雜的狀態可能需要更精細的管理和恢復機制。

????為何適合使用備忘錄模式分析：

• 備忘錄模式提供了一種在不破壞對象封裝性的前提下捕獲對象內部狀態，并在以后將該對象恢復到原先狀態的方式。
  備忘錄模式將狀態的保存和恢復邏輯分離開來，使得這些邏輯與對象本身的業務邏輯無關，從而提高了代碼的可維護性和可擴展性。
• 如果任務對象的狀態需要在執行過程中被保存，并在以后的某個時間點被恢復，那么備忘錄模式將是一個很好的選擇。
  通過使用備忘錄模式，我們可以將任務對象的狀態保存到備忘錄對象中，并在需要時從備忘錄對象中恢復任務對象的狀態。

????使用備忘錄實現的注意事項：👇

• 管理備忘錄的生命周期：
  備忘錄對象創建后需要在合適的時候被銷毀，以避免內存泄漏。系統需要主動管理備忘錄對象的生命周期，確保在不需要時及時刪除其引用。
• 考慮備忘錄的性能開銷：
  頻繁地創建和銷毀備忘錄對象可能會帶來性能開銷，特別是在處理大量數據或高頻操作時。因此，在使用備忘錄模式時需要權衡其帶來的好處和性能開銷。
• 保護備忘錄對象的安全性：
  備忘錄對象可能包含敏感信息，因此需要確保只有授權的代碼才能訪問和修改備忘錄對象。此外，還需要防止備忘錄對象被意外修改或破壞。
• 注意狀態的完整性和一致性：
  在保存和恢復對象狀態時，需要確保狀態的完整性和一致性。這意味著在恢復狀態時，對象應該能夠恢復到一個一致且可用的狀態，而不是一個無效或錯誤的狀態。

????何時選用備忘錄模式來實現：👇

• 當需要保存一個對象在某一時刻的狀態，并在以后能夠恢復該狀態時，可以使用備忘錄模式。這通常用于實現撤銷操作、歷史記錄或版本控制等功能。
• 當對象的狀態變化非常復雜或難以預測時，備忘錄模式可以提供一種靈活且可靠的方式來管理對象的狀態。通過保存對象的狀態到備忘錄對象中，可以在需要時隨時恢復對象到先前的狀態，而無需關心狀態變化的具體細節。
• 當需要保護對象狀態的安全性時，備忘錄模式也是一種很好的選擇。通過將對象的狀態封裝在備忘錄對象中，并限制對備忘錄對象的訪問權限，可以確保對象的狀態不會被外部代碼意外修改或破壞。

2.3 備忘錄模式結構圖及說明

• 發起人（Originator）：
  · 記錄當前時刻的內部狀態信息。
  · 提供創建備忘錄和恢復備忘錄數據的功能。
  · 實現其他業務功能，并可以訪問備忘錄里的所有信息。
  · 在備忘錄模式中，發起人負責創建一個備忘錄來存儲自己當前的內部狀態，同時它也可以使用備忘錄來恢復其內部狀態到之前保存的狀態。
• 備忘錄（Memento）：
  · 負責存儲發起人的內部狀態。
  · 在需要的時候提供這些內部狀態給發起人，以供恢復狀態。
  · 備忘錄可以根據需要決定存儲發起人的哪些內部狀態，并且防止發起人以外的對象訪問備忘錄。
  · 備忘錄通常提供兩個接口：窄接口（Caretaker可見）和寬接口（Originator可見）。寬接口允許發起人訪問備忘錄中的所有數據。
• 管理者（Caretaker）：
  · 負責保存備忘錄，但不能對備忘錄的內容進行操作或訪問。
  · 只負責將備忘錄傳遞給其他對象，如發起人。
  · 管理者對備忘錄進行管理，提供保存與獲取備忘錄的功能，但它對備忘錄內部存儲的狀態信息一無所知。

2.4 使用備忘務模式重構示例

????重構步驟
????為了重構上述代碼并解決其缺點，我們可以使用備忘錄模式來重構代碼。可以考慮以下步驟：👇

1. 引入接口和抽象類以增加靈活性和可擴展性。
2. 使用備忘錄模式來保存和恢復任務的狀態。
3. 分離控制臺輸出和業務邏輯。
4. 考慮持久化存儲。

下面是一個簡化的重構示例，其中應用了備忘錄模式來解決任務狀態的保存和恢復問題：👇

1. 定義任務接口

public interface Task {  String getDescription();  void setCompleted(boolean completed);  boolean isCompleted();  // 為備忘錄模式添加的方法  TaskMemento createMemento();  void restoreFromMemento(TaskMemento memento);  
}  

2. 具體的任務類實現任務接口

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();  }  
}  

3. 定義備忘錄類來保存任務的狀態

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;  }  
}  

4. 定義任務管理器類，負責任務的添加、列出、完成以及保存狀態等操作

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.");  }  }  
}  

5. 控制臺視圖類，負責與用戶交互和顯示信息（與控制臺輸出解耦）

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);  }  
}  

6. 主程序入口（示例）

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 重構后解決的問題👍

????優點
????上述實現解決了以下已知缺點：👇

1. 增加靈活性和可擴展性：
   ? 通過引入接口（Task）和抽象類，我們可以更容易地添加新的任務類型或修改現有任務的行為，而不需要更改使用它們的代碼。這符合“開閉原則”，即對擴展開放，對修改關閉。
2. 任務狀態的保存和恢復：
   ? 通過實現備忘錄模式，我們現在可以保存任務的狀態（TaskMemento）并在以后恢復它。這對于撤銷操作、歷史記錄或版本控制等功能非常有用。
3. 分離關注點：
   ? 通過將控制臺輸出和業務邏輯分離到不同的類中（ConsoleView和TaskManager），我們提高了代碼的可維護性和可讀性。ConsoleView負責處理用戶輸入和顯示信息，而TaskManager則專注于管理任務的狀態和行為。
4. 為持久化存儲做準備：
   ? 雖然上述示例中沒有直接實現持久化存儲，但通過將任務狀態保存在備忘錄列表中，我們已經為將來的持久化存儲打下了基礎。這個列表可以很容易地替換為數據庫或文件系統的實現。
5. 更好的封裝性：
   ? 備忘錄模式允許我們在不破壞對象封裝性的情況下捕獲和恢復其內部狀態。這意味著我們可以隱藏任務的內部實現細節，同時仍然能夠保存和恢復其狀態。

????注：上述實現并沒有完全解決所有可能的缺點或問題。例如，它并沒有處理并發訪問或線程安全的問題，也沒有實現完整的錯誤處理或用戶輸入驗證。這些功能在實際應用中可能是必要的，但需要根據具體的需求和上下文來設計和實現。

????遵循的設計原則
????上述示例使用備忘錄模式重構后的代碼遵循了以下設計原則：👇

1. 單一職責原則（SRP）：
   ?? 每個類只負責一項功能。例如，TaskManager 類負責管理任務，而 ConsoleView 類負責處理用戶輸入和顯示信息。這使得代碼更易于理解、維護和測試。

2. 開閉原則（OCP）：
   ?? 軟件實體（類、模塊、函數等）應該對擴展開放，對修改關閉。在上述實現中，通過引入接口和抽象類，可以更容易地添加新的任務類型或修改現有任務的行為，而不需要更改使用它們的代碼。

3. 里氏替換原則（LSP）：
   ?? 子類必須能夠替換其父類，并且不影響程序的行為。雖然上述實現中沒有明確顯示子類替換父類的情況，但如果我們有一個基于Task接口的具體任務類，我們應該能夠將其替換為任何其他實現了相同接口的任務類，而不會破壞程序的功能。

4. 接口隔離原則（ISP）：
   ?? 客戶端不應該依賴于它不使用的接口。在上述實現中，TaskManager 和 ConsoleView 只依賴于它們真正需要的接口，而不是整個系統的所有接口。這有助于減少類之間的耦合度。

5. 依賴倒置原則（DIP）：
   ?? 高層模塊不應該依賴于低層模塊，它們都應該依賴于抽象。在上述實現中，通過使用接口（如 Task）和抽象類，高層模塊（如 TaskManager）與低層模塊（具體的任務實現）之間的依賴被最小化。這使得代碼更加靈活和可重用。

   還可能遵循了其他設計原則，如：

6. 迪米特法則（LoD）或最少知識原則：
   ?? 一個對象應該對其他對象保持最少的了解。在上述實現中，各個類之間通過接口進行交互，而不是直接操作其他類的內部狀態或方法。這有助于降低類之間的耦合度。

7. 合成復用原則：
   ?? 盡量使用對象組合/聚合，而不是繼承關系達到軟件復用的目的。在上述實現中，可以看到通過組合不同的對象（如 TaskManager 和 ConsoleView）來實現整體功能，而不是通過繼承來擴展功能。這有助于提高代碼的靈活性和可維護性。

????缺點
????任何實現都不可能完美，上述實現同樣可能存在一些缺點或潛在的改進點。以下是一些可能存在的缺點：👇

1. 缺乏異常處理：
   💡 在上述實現中，可能沒有明顯的異常處理機制。這意味著如果發生錯誤（如無效的用戶輸入、任務執行失敗等），程序可能會崩潰或產生不可預測的行為。為了增加健壯性，應該添加適當的異常處理代碼。
2. 用戶輸入驗證不足：
   💡 ConsoleView 類在處理用戶輸入時可能沒有進行充分的驗證。這可能導致非法或意外的輸入被接受，從而影響程序的正常運行。應該對用戶輸入進行嚴格的驗證和清洗。
3. 硬編碼和魔數：
   💡 如果實現中包含了硬編碼的值（如固定的任務類型、狀態代碼等），那么這些值在未來的修改中可能會變得非常困難。應該使用常量、枚舉或配置文件來管理這些值，以便更容易地進行更改。
4. 線程安全性問題：
   💡 如果多個線程同時訪問和修改共享資源（如任務列表），可能會發生數據不一致的問題。上述實現可能沒有考慮線程安全性，這在多線程環境中是一個潛在的問題。可以通過同步機制（如鎖）來解決這個問題。
5. 可擴展性的局限性：
   💡 雖然實現中使用了接口和抽象類來增加靈活性，但在某些方面可能仍然存在可擴展性的局限性。例如，如果需要添加新的視圖類型（不僅僅是控制臺視圖），則可能需要修改現有的代碼結構。可以通過使用更高級的設計模式（如工廠模式、策略模式等）來進一步提高可擴展性。
6. 缺乏日志記錄和監控：
   💡 在實際應用中，日志記錄和監控是非常重要的功能，可以幫助開發人員診斷和解決問題。上述實現中可能沒有包含這些功能，這可能會使得問題難以追蹤和解決。
7. 性能考慮：
   💡 如果任務列表變得非常大，或者任務的執行變得非常頻繁，那么性能可能會成為一個問題。在這種情況下，可能需要考慮使用更高效的數據結構或算法來優化性能。

????注：這些缺點并不一定都存在于上述實現中，而是根據一般的經驗和最佳實踐提出的潛在問題點。具體的缺點取決于實現的細節和使用場景。因此，在評估一個實現的優缺點時，應該結合具體的上下文和需求來進行分析。

三、模式講解🎭

??核心思想

備忘錄模式核心思想是“保存一個對象的某個狀態，以便在適當的時候恢復對象”

????具體來說，備忘錄模式通過引入一個備忘錄類（Memento）來存儲原始對象（Originator）的內部狀態，并提供了創建和恢復備忘錄的方法。原始對象可以根據需要創建備忘錄，并將當前狀態保存到備忘錄中。當需要恢復原始對象的狀態時，可以使用備忘錄中的信息來恢復。

????備忘錄模式的關鍵在于將存儲狀態的責任從原始對象轉移到備忘錄對象中，從而降低了原始對象與狀態存儲之間的耦合度。這種分離使得原始對象可以獨立地變化和演進，而不會影響到狀態的存儲和恢復機制。

3.1 認識備忘錄者模式

????本質

備忘錄模式的本質是：保存和恢復原始對象的內部狀態。

????備忘錄模式提供了一種在不破壞封裝性的前提下捕獲對象內部狀態并在對象外部保存這個狀態的方式，從而使我們能夠方便地將對象恢復到之前的狀態。

????目的
????為了在以后的某個時候，將該對象的狀態恢復到備忘錄所保存的狀態。

????功能
????備忘錄模式的功能是保存和恢復對象的內部狀態，提供了一種靈活的狀態管理機制。它可以幫助你實現撤銷操作、事務回滾、防止狀態丟失以及提供歷史記錄等功能，提高軟件的靈活性和用戶體驗。它的功能主要體現在以下幾個方面：👇

1. 保存對象狀態：
   🌈 備忘錄模式允許在不破壞對象封裝性的前提下，捕獲對象的內部狀態，并在對象之外保存這個狀態。這意味著你可以將對象恢復到之前保存的狀態，提供了一種狀態恢復的機制。
2. 支持撤銷操作：
   🌈 備忘錄模式常用于需要撤銷或回滾操作的場景。通過保存對象的狀態，你可以輕松地撤銷之前的操作，將對象恢復到之前的狀態。這在許多應用中都是非常有用的功能，比如文本編輯器、圖形編輯器等。
3. 實現事務回滾：
   🌈 在數據庫事務處理中，備忘錄模式可以用于實現事務回滾功能。當執行一個事務時，可以在執行之前創建一個備忘錄對象來保存當前狀態。如果事務執行失敗，可以使用備忘錄對象恢復之前保存的狀態，保證數據的一致性。
4. 防止狀態丟失：
   🌈 在復雜的系統中，對象的狀態可能會被其他對象修改，導致狀態丟失或不一致。備忘錄模式可以用于保存對象的狀態，并在需要時恢復該狀態，從而防止狀態丟失。
5. 提供歷史記錄功能：
   🌈 備忘錄模式可以用于實現歷史記錄功能。通過保存對象在不同時間點的狀態，你可以記錄對象的歷史狀態，并提供一種方式來查看或回退到之前的狀態。這在許多應用中都是有用的功能，比如版本控制系統、游戲存檔等。

????備忘錄對象
????在備忘錄模式中，備忘錄對象（Memento）的作用主要是存儲另外一個對象（即發起人對象，Originator）的內部狀態的快照。這樣，備忘錄對象可以作為一個外部化的存儲結構，保存發起人對象在某個時間點的內部狀態。

????通過這種方式，備忘錄模式允許在不破壞對象封裝性的前提下，將對象的狀態保存到外部，從而可以在將來合適的時候，通過備忘錄對象將這個狀態恢復給發起人對象。這提供了一種靈活的狀態管理機制，使得發起人對象可以自由地改變其內部狀態，同時又有能力恢復到之前保存的狀態。

????發起人對象
????發起人對象在備忘錄模式中的作用是創建和使用備忘錄對象來保存和恢復其內部狀態，并提供與備忘錄對象相關的其他業務功能。它是實現狀態保存和恢復功能的關鍵角色之一，與備忘錄對象和管理者對象一起協作完成備忘錄模式的各項任務。

• 首先，發起人對象負責創建一個備忘錄對象（Memento），用來記錄其當前的內部狀態。
  這個內部狀態可以是發起人對象的任何重要屬性或狀態信息，需要在將來的某個時刻進行恢復。
• 其次，發起人對象可以使用備忘錄對象來恢復其內部狀態。
  當發起人對象需要恢復到之前保存的狀態時，它可以從備忘錄對象中獲取相應的狀態信息，并使用這些信息來恢復自己的狀態。
• 此外，發起人對象還可以提供其他業務功能，并可以訪問備忘錄對象中的所有信息。
  這意味著發起人對象在備忘錄模式中扮演著核心角色，不僅負責創建和使用備忘錄對象，還負責處理與備忘錄對象相關的所有操作。

????管理者對象
????在備忘錄模式中，管理者對象（Caretaker）的作用主要是負責保存備忘錄對象，但不能對備忘錄對象的內容進行訪問或操作。管理者對象可以存儲一個或多個備忘錄對象，并提供相應的接口來管理這些備忘錄對象，例如增加、刪除和獲取備忘錄對象等操作。
????然而，需要注意的是，管理者對象并不了解備忘錄對象的具體內容，它只是簡單地將備忘錄對象存儲起來，并在需要的時候提供相應的備忘錄對象給發起人對象，以便發起人對象可以恢復其內部狀態。

????管理者對象在備忘錄模式中的作用是提供一個存儲和管理備忘錄對象的機制，確保備忘錄對象的安全性和可用性，從而實現狀態保存和恢復功能。它是備忘錄模式中的重要組成部分，與發起人對象和備忘錄對象一起協同工作，實現靈活的狀態管理。

3.2 實現步驟

????備忘錄模式的實現通常涉及以下步驟和組件：

1. 定義備忘錄類（Memento）
   備忘錄類負責存儲原始對象的內部狀態。它通常包含與原始對象狀態相對應的屬性和訪問這些屬性的方法。備忘錄類應該防止原始對象以外的對象訪問備忘錄。備忘錄可以存儲原始對象的任何必要狀態，以便以后可以完全恢復。
2. 定義原始對象類（Originator）
   原始對象是需要保存狀態的對象。它通常包含一些內部狀態和一個創建備忘錄的方法，以及一個使用備忘錄恢復狀態的方法。原始對象負責在需要時創建備忘錄，并可以使用備忘錄來恢復其狀態。
3. 定義管理者類（Caretaker）
   管理者類負責保存備忘錄對象，并在需要的時候提供備忘錄對象以恢復原始對象的狀態。管理者類通常不直接操作備忘錄對象的內容，只是簡單地存儲和提供備忘錄。
4. 實現備忘錄的存儲和恢復操作
   現在我們已經定義了備忘錄模式中的三個主要類，接下來是實現備忘錄的存儲和恢復操作。這通常涉及在客戶端代碼中使用這些類。

3.3 思考備忘錄模式

????備忘錄模式（Memento Pattern）與其他一些設計模式在某些方面有相似之處，但每種模式都有其獨特的應用場景和目的。以下是一些與備忘錄模式相似的設計模式：👇

1. 命令模式（Command Pattern）：
   命令模式將請求封裝為一個對象，從而允許使用不同的請求將客戶端與服務端操作解耦。它也可以支持撤銷操作，類似于備忘錄模式能夠恢復對象到之前的狀態。但兩者的區別在于，命令模式關注的是操作的封裝和參數化，而備忘錄模式關注的是對象狀態的保存和恢復。
2. 狀態模式（State Pattern）：
   狀態模式允許一個對象在其內部狀態改變時改變它的行為。與備忘錄模式相似，狀態模式也涉及到對象狀態的變化。然而，狀態模式主要關注狀態轉換和基于狀態的行為變化，而備忘錄模式則專注于在不破壞封裝性的前提下捕獲和恢復對象的內部狀態。
3. 迭代器模式（Iterator Pattern）：
   迭代器模式提供一種方法，可以順序訪問聚合對象中的各個元素，而無需暴露其底層表示。雖然迭代器模式與備忘錄模式在表面上看似不相關，但它們都提供了一種訪問對象內部信息的方式，同時保持了對象的封裝性。迭代器模式關注于遍歷集合，而備忘錄模式關注于保存和恢復狀態。
4. 原型模式（Prototype Pattern）：
   原型模式用于創建重復的對象，同時又能保證性能。它通過復制已有對象來創建新對象，而不是通過實例化類。在某些方面，原型模式與備忘錄模式相似，因為它們都涉及對象的復制。然而，原型模式主要關注對象的創建和性能優化，而備忘錄模式則關注對象狀態的保存和恢復。

四、總結🌟

4.1 優點💖

????備忘錄模式（Memento Pattern）允許在不破壞封裝性的前提下捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。以后可以將該對象恢復到原先保存的狀態。以下是對備忘錄模式優點的分析：👇

1. 保持封裝性：
   備忘錄模式通過創建一個備忘錄對象來存儲發起人的內部狀態，而無需將發起人的內部細節暴露給外部。這樣，發起人的內部狀態可以被安全地保存和恢復，而不會破壞其封裝性。
2. 提供狀態恢復機制：
   備忘錄模式為發起人對象提供了一種恢復其之前狀態的有效機制。通過保存發起人對象在不同時間點的狀態快照，可以在需要時將發起人對象恢復到任何一個先前保存的狀態。
3. 支持歷史狀態管理：
   備忘錄模式可以與管理者對象結合使用，以支持對歷史狀態的管理。管理者對象可以存儲多個備忘錄對象，形成一個狀態歷史記錄。這使得發起人對象可以回滾到任意歷史狀態，實現復雜的狀態管理需求。
4. 靈活性：
   備忘錄模式提供了很大的靈活性。發起人對象可以自由地創建、保存和恢復備忘錄對象，而無需關心備忘錄對象的具體實現細節。此外，備忘錄對象可以被存儲在不同的存儲介質中，如內存、文件或數據庫等，以滿足不同的應用需求。
5. 簡化錯誤處理：
   當系統操作可能導致不可預測的狀態變化時，備忘錄模式可以簡化錯誤處理。通過保存操作前的狀態，并在操作失敗時恢復該狀態，可以確保系統的一致性和穩定性。
6. 支持撤銷和重做功能：
   備忘錄模式是實現撤銷和重做功能的一種有效手段。通過保存操作前后的狀態快照，可以在用戶請求撤銷或重做時恢復相應的狀態。這對于需要支持用戶操作歷史的應用（如文本編輯器、繪圖工具等）非常有用。

4.2 缺點

????備忘錄模式（Memento Pattern）雖然為對象狀態的保存和恢復提供了有效的機制，并在許多場景下非常有用，但它也存在一些潛在的缺點和考慮因素：👇

1. 內存消耗：
   備忘錄模式的一個主要缺點是它可能導致大量的內存消耗。這是因為每個備忘錄對象都需要存儲發起人對象的一個完整狀態快照。如果發起人對象的狀態非常大，或者需要頻繁地保存狀態，那么將創建大量的備忘錄對象，從而占用大量的內存空間。
2. 隱私和安全性問題：
   備忘錄模式需要保存發起人對象的內部狀態，這可能引發隱私和安全性問題。如果狀態信息包含敏感數據，如密碼、個人身份信息或商業機密，那么在不安全的環境中存儲或傳輸備忘錄對象可能會暴露這些信息。
3. 依賴性和耦合性：
   備忘錄模式通常要求發起人對象與備忘錄對象之間存在緊密的耦合關系。發起人對象需要知道如何創建和恢復備忘錄對象，這可能限制了系統的靈活性和可擴展性。此外，如果備忘錄對象的實現發生變化，可能需要修改發起人對象的代碼，這違反了“開閉原則”。
4. 版本控制問題：
   在長時間運行的系統中，隨著時間的推移，發起人對象的狀態可能會經歷多次變化。如果每個狀態變化都保存一個備忘錄對象，并且沒有有效的版本控制機制來管理這些對象，那么恢復到特定狀態可能會變得復雜和困難。
5. 復雜性增加：
   備忘錄模式增加了系統的復雜性。需要設計和管理額外的備忘錄對象和管理者對象，以及處理它們之間的交互。這可能會增加開發、測試和維護的工作量。
6. 不支持跨平臺或跨語言恢復：
   在某些情況下，備忘錄對象可能無法在不同的平臺或編程語言之間共享或恢復。這限制了系統的互操作性和可移植性。

4.3 挑戰和局限

????備忘錄模式（Memento Pattern）用于捕獲和恢復對象的內部狀態。然而，像所有設計模式一樣，它也有其挑戰和局限性。以下是對備忘錄模式存在的一些挑戰和局限的分析：👇
????挑戰

1. 管理備忘錄的生命周期：
   備忘錄對象可能占用大量內存，特別是在需要頻繁保存狀態或狀態本身很大的情況下。
   需要決定何時創建備忘錄、何時刪除不再需要的備忘錄，以及如何有效地存儲和檢索它們。

2. 確保狀態的一致性和完整性：
   當對象狀態由多個屬性組成時，必須確保在創建備忘錄時捕獲所有相關狀態，并且在恢復狀態時能夠完整地恢復它。
   如果狀態的一部分在備忘錄創建后被外部修改，那么在恢復時可能會出現狀態不一致的情況。

3. 處理并發訪問：
   在多線程環境中，必須確保在創建或恢復備忘錄時對象狀態不會被其他線程同時修改，否則可能會導致數據競爭或不一致的狀態。

4. 保持簡潔性和可理解性：
   備忘錄模式增加了系統的復雜性。需要確保代碼保持簡潔和易于理解，以便其他開發人員能夠輕松地維護和擴展系統。

????局限

1. 隱私和安全性的局限性：
   如果備忘錄存儲了敏感信息，那么它可能會成為安全漏洞的來源。必須采取額外的預防措施來保護這些數據，例如加密存儲或使用訪問控制機制。
2. 跨平臺和互操作性的限制：
   備忘錄對象的實現可能依賴于特定的編程語言或平臺特性。這可能會限制系統的跨平臺兼容性或與其他系統的互操作性。
3. 可能違反封裝原則：
   為了允許外部創建和恢復備忘錄，發起人可能需要暴露其內部狀態的一部分。這可能會破壞對象的封裝性，使得內部實現細節對外部可見。
4. 不適用于所有類型的狀態：
   有些狀態可能不適合使用備忘錄模式來保存和恢復。例如，與外部環境緊密相關的狀態（如打開的文件句柄或網絡連接）可能無法有效地在備忘錄中捕獲和恢復。
5. 性能開銷：
   創建、存儲和恢復備忘錄對象可能會帶來顯著的性能開銷，特別是在處理大量狀態或需要高頻狀態保存的場景中。