備忘錄模式提供了一種彌補真實世界缺陷的方法，讓」後悔藥」在程式的世界中真實可行，其定義如下:
在不破壞封裝性的前提下，捕獲乙個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。
originator發起人角色
記錄當前時刻的內部狀態，負責定義哪些屬於備份範圍的狀態，負責建立和恢復備忘錄資料。
memento備忘錄角色
負責儲存originator發起人物件的內部狀態，在需要的時候提供發起人需要的內部狀態。
caretaker備忘錄管理員角色
對備忘錄進行管理、儲存和提供備忘錄。
(1)備忘錄的生命期
備忘錄建立出來就要在」最近」的**中使用，要主動管理它的生命週期，建立就要使用，不使用就要立刻刪除其引用，等待垃圾**器對它的**處理。
(2)備忘錄的效能
不要在頻繁建立備份的場景中使用備忘錄模式(比如乙個for迴圈)，
原因有二:
一是控制不了備忘錄建立的物件數量;
二是大物件的建立是要消耗資源的，系統的效能需要考慮。
因此，如果出現這樣的**，設計師就應該好好想想怎麼修改架構了。
注意:使用clone方式的備忘錄模式，可以使用在比較簡單的場景或者比較單一的場景中，盡量不要與其他的物件產生嚴重的耦合關係。
注意:如果要設計乙個在執行期間決定備份狀態的框架，則建議採用aop框架來實現，避免採用動態**無謂地增加程式邏輯複雜性。
注意:記憶體溢位問題，該備份一旦產生就裝入記憶體，沒有任何銷毀的意向，這是非常危險的。因此，在系統設計時，要嚴格限定備忘錄的建立，建議增加map的上限，否則系統很容易產生記憶體溢位情況。
在系統管理上，乙個備份的資料是完全、絕對不能修改的，它保證資料的潔淨，避免資料汙染而使備份失去意義。在我們的設計領域中，也存在著同樣的問題，備份是不能隨便篡改的，也就是說需要縮小備份出的備忘錄的閱讀許可權，保證只能是發起人可讀就成了。
備忘錄模式是我們設計上」月光寶盒」，可以讓我們回到需要的年代;是程式資料的」後悔藥」,吃了它就可以返回上乙個狀態;是設計人員的定心丸，確保即使在最壞的情況下也能獲得最近的物件狀態。如果大家看懂了的話，請各位在設計的時候就不要使用資料庫的臨時表作為快取備份資料了，雖然是乙個簡單辦法，但是它加大了資料庫操作的頻繁度，把壓力下放到資料庫了，最好的解決辦法就是使用備忘錄模式。
**例子:
設計之禪 備忘錄模式
備忘錄模式是非常簡單的一種模式，應用場景非常廣泛，如編輯器的ctrl z 資料庫事務的回滾 遊戲的存檔等等都符合該模式的思想 備份 比較疑惑為什麼叫備忘錄模式，叫備份模式不是更貼切麼？備忘錄模式就是將乙個物件的內部狀態儲存到物件的外部，這樣，在將來的任一時間點都可以恢復到之前的狀態，讓我們有後悔藥可...
設計模式之備忘錄模式
機器 public class machine public void startplay disc.setluminance 60 disc.settime 0 disc.setvolume 80 public void stopplay disc.setluminance 70 disc.set...
設計模式之備忘錄模式
定義 在不破壞封閉的前提下，捕獲乙個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。備忘錄模式有三個角色 以儲存遊戲進度為例，退出遊戲前存檔，再進入遊戲就會顯示退出之前的狀態。示例 遊戲發起人類 public class game public state cr...