備忘錄模式的官方定義：
在不破壞封裝性的前提下，獲取乙個物件的內部狀態，並在該物件之外儲存這些狀態。這樣以後就可以通過該物件恢復到原先儲存的狀態。
大白話說：
乙個物件中一般都封裝了很多屬性，這些屬性的值會隨著程式的執行而變化。當我們需要儲存某一時刻物件的某些值的時候，我們就再建立乙個物件，將當前物件中的一些屬性儲存到新的物件中，當我們需要恢復的時候再從新的物件中取出屬性值即可。這種想法就是備忘錄模式。
備忘錄模式的類圖：
1.需要備份的類是orginator，備份的資料儲存在mementor中，由caretaker來管理mementor。
2.orginator中必須含有兩個函式，乙個是createmementor()，用來建立mementor物件，並將需要備份的資料儲存到該物件中；另外乙個是setmementor(mementor)，用來恢復資料，將傳入的mementor物件中的資料取出來，賦給當前物件中的屬性。
不用備忘錄模式進行備份物件資訊：
呼叫者使用別人提供給我們的orginator物件，用著用著我們突然想要儲存orginator物件中的資料了，此時我們一般會再建立個orginator物件，把需要儲存的資料乙個個地複製到新的orginator物件中去。然後當我們需要還原的時候，再將新orginator物件中的資料乙個個拷到舊的orginator物件中去。
這種方式有個巨大的缺陷：
我們在儲存屬性的時候需要記住儲存了哪些屬性，好在還原的時候將這些屬性再複製給原來的物件。如果需要儲存的屬性發生了變化，那麼我們還需要修改自己的**。
使用了備忘錄模式的好處：
使用了備忘錄模式之後，對方在提供給我們orginator類的基礎上還給我們提供了mementor、caretaker類。我們客戶端只需要在需要備份的地方呼叫createmementor()函式，需要還原的地方呼叫set
mementor。如果需要備份的屬性發生了變化，那也只是第三方類庫orginator、
mementor進行了修改，對於我們客戶端來說，**不需要任何修改。
備忘錄模式與轉殖的區別？
有的人說，備忘錄模式就是用來儲存物件中一些屬性，那麼當我們需要備份物件中屬性的時候完全可以轉殖這個物件嘛，何必採用構造這麼複雜的備忘錄模式呢？
原因有以下幾點：
1.進行一次轉殖會將物件的全部屬性都複製到乙個新的物件中去，而當我們僅需要備份物件中一部分屬性的時候就只能使用備忘錄模式。
ps：在只備份一部分屬性的時候也可以新建乙個物件，然後把需要備份的屬性一一複製給新物件中；然後當還原的時候再一一複製到原本的物件中去。但這樣做太爛了！因為客戶端在備份的時候必須要記住哪些屬性備份了，好在還原的時候還原這些屬性。而且當需要備份的屬性發生變化的時候，必須修改客戶端**，這很不科學。
2.使用備忘錄模式之後，當需要備份的屬性發生變化後，只需修改orginator類和mementor類，無需修改客戶端**。
3.使用備忘錄模式之後，備份資料雖然交給了其他物件儲存，但物件的備份操作和還原操作都是通過物件本身的函式實現的，因此體現了封裝的思想。
什麼時候使用備忘錄模式？
當乙個物件需要記錄其歷史屬性，並且需要記錄的屬性是所有屬性的一部分時，可以使用備忘錄模式記錄屬性。
備忘錄模式
備忘錄模式 memento 在不破壞封裝性的前提下，捕獲乙個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。originator 發起人 負責建立乙個備忘錄memento，用以記錄當前時刻它的內部狀態，並可以使用備忘錄恢復內部狀態。originator可根據需要...
備忘錄模式
先從物件導向的三大特徵之一封裝說起。物件導向的封裝簡單點說就是把狀態 資料 和行為 操作這些資料的方法 放到一起，構成乙個單元，通常叫做類。乙個物件的行為是事先確定好的 靜態 一些指令碼，如果物件的狀態相同，物件看起來就是一樣的。所以當我們需要把乙個物件的某一時刻儲存起來，那麼只需要儲存它在那個時刻...
備忘錄模式
面臨問題 物件狀態的變化無端，如何回溯恢復物件在某個點的狀態？在軟體構建過程中，某些物件的狀態在轉換過程中，可能由於某種需要，要求程式能夠回溯到物件之前處於某個點時的狀態。如果使用一些公用介面來讓其他物件得到物件的狀態，便會暴露物件的細節實現。如何實現物件狀態的良好儲存與恢復？但同時又不會因此而破壞...