一般來說解耦有兩條途徑，一是遠端請求，二是訊息（推送）。這兩種方式可以說使用的應用場景不一樣，比如說遠端請求這是主動方在呼叫方，而推送的主動權肯定是在生產方。
為什麼要解耦？這個。。。
如果用訊息進行應用間解耦，訊息將作為應用間的介質作為上下文傳輸。其實知道生產者和消費者就很容易明白，這樣兩個應用之間將不會有任何**的依賴。
這樣會有乙個訊息提供方和訊息接收方。也可以說是訊息生產方和訊息消費方。兩者之間並不知道彼此的存在，其實嚴格的講訊息消費方是知道生產方的，不過是一種非常弱的依賴。這是一種推送模式，所謂推送模式就是消費生產方一直生產訊息，再推送給各個消費方，這樣消費方就可以進行接收訊息進行消費。
下面看一下系統呼叫圖：
這裡訊息中心是對訊息重新抽取出來的一層，這樣保證應用層職責更加單一，另外乙個不會因為訊息的堆積導致服務癱瘓（一般來說訊息中心都部署在新的機器上，不太會和其他應用耦合）。訊息中心存放了生產方傳送過來的訊息然後再進行集中**。這樣可以在訊息中心實現一些訊息的處理邏輯以滿足更多的業務需求。比如說閥值，可能生產方非常強悍，而消費方比較弱，這樣長期會導致訊息堆積越來越多。而解決這樣的問題一般就是消費方使用集群來分攤壓力。簡單的應用場景訊息中心的意義不大，因為這樣會增加因為傳輸帶來的網路開銷，而中訊息中心本身是需要接收和**的，這中間肯定也會有資源消耗。
目前模式大概有兩種，第一是點對點(p2p)，就是單挑；一種是一對多，也就說所謂的發布/訂閱模式。這兩種方式其實本質上可以歸結為一種。發布/訂閱模式消費方需要在訊息中心註冊乙個賬號。讓訊息中心知道你的存在，到時候就會給你傳送訊息。
自然框架 之「解耦」初探
解耦，在以前確實做不到，但是周四和 橫刀天笑 聊了之後，發現解耦是可以實現的。其實很簡單，只要弄出來乙個 實體類 就可以搞定了。如果是簡單的情況，那麼就讓表單控制項 全權負責 了，這時候是不需要些什麼 的，點點滑鼠，打幾個字就可以了。如果是有複雜的業務邏輯，那麼就可以定義乙個實體類，然後讓表單控制項...
iOS 工程解耦後 訊息傳遞方式
根據上節的介紹，工程之間傳遞訊息可以新增互相的依賴來實現，不過依賴所能解決的問題有一定的侷限性，如 bu1 對bu2 需要傳遞訊息，可以新增bu1對bu2的依賴，但是如果同時bu2對bu1也要傳遞訊息時，依賴就無法解決了，下面介紹一種更加系統的方法 注 這種方法只適用於上節介紹的解耦方法，其他的不一...
模板用於解耦
一道 c 思考題 std string 的 operator 和 operator 是如何宣告的，如何避免與 iostream 的過度耦合？iostream 和 string 都可以單獨 include 來使用，顯然 iostream 標頭檔案裡不會定義 string 的 和 操作。那麼 strin...