委托delegation；
通知中心Notification Center；
-
鍵值觀察key value observing，KVO
上面的三種模式是什么？
三種模式都是一個對象傳遞事件給另外的對象，并且不要他們有耦合。這三種模式給對象提供了通信的方法。
一、delegate
delegation的基本特征是，一個controller定義了一個協議（即一系列的方法定義）。該協議描述了一個delegate對象為了能夠響應一個controller的事件而必須做的事情。協議就是delegator說，“如果你想作為我的delegate，那么你就必須實現這些方法”。
1.delegate的優勢：
- 1.非常嚴格的語法。所有監聽到的事件都可以在delegate協議中找到清晰的定義。
- 2.如果delegate中的一個方法沒有實現那么就會出現編譯警告/錯誤
- 3.能夠接收調用的協議方法的返回值。這意味著delegate能夠提供反饋信息給controller
2.缺點：
- 1.需要定義很多代碼：1.協議定義；2.聲明delegate屬性；3.在delegate本身中實現delegate方法定義
- 2.聲明屬性時，如果不用weak弱應用，會出現循環引用，導致內存泄漏。
- 3.在一個controller中有多個delegate對象，并且delegate是遵守同一個協議，但還是很難告訴多個對象同一個事件，不過有可能。
二、notification
在IOS應用開發中有一個”Notification Center“的概念。它是一個單例對象，允許當事件發生時通知一些對象。
1.優勢：
- 1.不需要編寫多少代碼，實現比較簡單；
- 2.對于一個發出的通知，多個對象能夠做出反應，即1對多的方式實現簡單
- 3.controller能夠傳遞context對象（dictionary），context對象攜帶了關于發送通知的自定義的信息
2.缺點：
- 1.通知發出后，controller不能從觀察者獲得任何的反饋信息。
- 2.在釋放注冊的對象時，需要在通知中心取消注冊；
- 3.在編譯期不會檢查通知是否能夠被觀察者正確的處理；
- 4.在調試的時候應用的工作以及控制過程難跟蹤；
- 5.需要第三方對喜愛那個來管理controller與觀察者對象之間的聯系；
- 6.controller和觀察者需要提前知道通知名稱、UserInfo dictionary keys。如果這些沒有在工作區間定義，那么會出現不同步的情況；
三、KVO
KVO是一個對象能夠觀察另外一個對象的屬性的值，并且能夠發現值的前后變化。
1.優點：
- 1.能夠提供一種簡單的方法實現兩個對象間的同步。例如：model和controller之間同步；
- 2.能夠對非我們創建的對象，即內部對象的狀態改變作出響應，而且不需要改變內部對象（SKD對象）的實現；例：對單個NSOperation 屬性isCancelled、isFinished通過kvo監控，執行完畢之后獲得通知。
- 3.能夠提供觀察的屬性的最新值以及先前值；
- 4.用key paths觀察嵌套對象；
2.缺點：
- 1.觀察的屬性必須使用strings來定義，編譯器不會出現警告以及檢查；
- 2.對屬性重構將導致我們的觀察代碼不再可用；
- 3.如果觀察者正在觀察多個值，則需要很多的if語句判斷。這是因為所有的觀察代碼通過一個方法來指向。
- 4.當釋放觀察者時需要移除觀察者。
四、總結：
每一種模式都給對象提供一種方法來通知一個事件給其他對象，而且前者不需要知道偵聽者。
1.在這三種模式中，我認為KVO有最清晰的使用案例，而且針對某個需 求有清晰的實用性，監控屬性。
2.我發現用通知中心很難把握應用的執行流程。而且在公共空間需要定義太多的常量。對于一個工作于現有的項目的開發者來說，如果過分的使用 通知中心，那么很難理解應用的流程。
3.使用代理方法將增強代碼的可讀性，以及更好的跟蹤你的app。代理協議發生改變以及實現都可通過編譯器檢查出來，如果沒有將會在開發的過程中至少會出現crash，而不僅僅是讓一些事情異 常工作。
4.當然會有delegation模式不適合的例外情況出現，而且notification可能更加有效。例如：應用中所有的controller需要知道一個事件。然而這些類型的場景很少出現。另外一個例子是當你建立了一個架構而且需要通知該事件給正在運行中應用。
根據經驗，如果是屬性層的事件，不管是在不需要編程的對象還是在緊緊綁定一個view對象的model對象，我只使用kvo。對于其他的事件，我都會使用delegate模式。如果因為某種原因我不能使用delegate，首先我將估計我的app架構是否出現了嚴重的錯誤。如果沒有錯誤，然后才使用 notification。
