對象間交互模式2017-06-22 11:32程序設計/設計推薦人：feizhu422

　　前言

　　直白的對象間交互

　　輕度抽象的對象間交互

　　使用Target-Action淡化接口概念的對象間交互

　　響應式的對象間交互

　　基于閉包的對象間交互

　　推導過程

　　總結

　　前言

　　閉包在什么場景下才是最優(yōu)選擇？理由？補充說明一下：很多場景都適用閉包，但不是所有場景下閉包都是最優(yōu)選擇。

　　這篇文章主要就是回答這個問題的。

　　但是在直接切入閉包之前，我們需要有一個推導的過程，在推導過程之前，我們還需要梳理一下現(xiàn)有的交互模式。所以，關于這篇文章的內容，更確切地說應該是討論了對象間各種交互方式。

　　這個主題其實很早之前業(yè)界也討論過，objc.io很早就有《Communication Patterns》這篇文章詳細講過這個問題。這篇文章在很多地方說得都是對的，但這篇文章在block的討論上不夠全面。國內也有很多人關于對象間交互的問題寫過文章，但這些文章相比《Communication Patterns》來說，就已經(jīng)錯得十分離譜了。

　　本文是從另一個角度討論了同樣的問題，文末給的決策圖可以作為《Communication Patterns》的補充去做參考。

　　直白的對象間交互

　　解決對象間交互問題的最直白樸素的做法就是直接傳值，直接調用。

　　適用這種做法的前提是你非常確認A對象的信息來源只可能是B對象，而且在未來這個前提也是不會產生任何改變。這個前提在某些場景下是成立的，例如你要取timestamp，那么只可能從NSDate中取。你要操作字符串，也只可能使用NSString。我這里說的是通常的環(huán)境，當然，針對NSDate或NSString這類對象做二次封裝導致不直接依賴NSDate或NSString的場景也是有的，其本質依舊不變。

　　這種做法的好處在于可以限制實現(xiàn)手段的多樣性，在維護代碼的時候工程師能夠更加容易地去聚焦問題所在。

　　存在限制不一定是壞的，靈活度高也不一定是好的。當一個工程中為了解決同一個問題而存在多種方案的