coupling, 即兩個東西之間的一種連線，使他們彼此關聯。
以前大學裡學軟體工程和物件導向的時候，就時常聽到解耦和低耦合，所以現在在做開發的時候，也往往會去想，怎麼降低耦合度呢。
軟體工程書籍中，這麼寫道，高內聚及低耦合可以給我們軟體開發人員帶來可讀性、復用性、可維護性和易變更性。
軟體開發過程中，耦合是不可避免的，除非做出來乙個超級巨大，包含一切功能的類/模組，都放在裡面做（這顯然並不是高內聚，只是把亂七八糟的揉在一起），否則模組與模組之間必然存在一定的耦合。
既然耦合不可避免，那高耦合和低耦合，又會對開發和維護產生什麼影響呢？
高耦合，也就意味著兩者之間存在強的關聯，比如強持有、雙向依賴、多個變數/常量的互相訪問，如此也就造成其中乙個需要更改的時候，另乙個類也需要大量更改，而在runtime的領域，則可能發生其中乙個導致另乙個不能釋放。尤其實際生產過程中，往往不只是兩個類有耦合關係，會有更多的類，從而產生一條耦合鏈。
低耦合，即兩者之間關聯較弱，比如廣播，dataflow架構，單向單依賴等等。組合優於繼承這個說法，也是從業務模型的角度，組合有時候相對於繼承降低了耦合。
高耦合的代價，從開發人員角度來說，會導致
低耦合的代價，則可能會需要付出效能、**行數、更多的時間去設計和解耦。
耦合，緊耦合，松耦合，解耦
一 耦合 耦合是兩個或多個模組之間的相互關聯。在軟體工程中，兩個模組之間的耦合度越高，維護成本越高。因此，在系統架構的設計過程中，應減少各個模組之間的耦合度，以提高應用的可維護性。二 緊耦合 緊耦合架構本質是client server的模型，如下圖所示 優點是 架構簡單 設計簡單 開發周期短 能夠快...
耦合還是解耦合？
我們的許多設計思想中很多地方都體現了解耦合的思想，這是 b 應對易於變化 b 的一種很好的解決手段，而在這些手段中最重要的解決方法就是 b 新增中間層 b 所謂新增中間層 比如我們常見的面向介面程式設計，其實就是新增了乙個中間的層次，遮蔽掉了一些變化，還有就是我們常用的設計模式，什麼 啊，faced...
訊息耦合還是介面耦合
訊息耦合還是介面耦合 最近公司準備開發乙個新產品，需要重新設計一套新的框架，但是就這框架中各模組的通訊方式，大家產生了爭論，主要集中在各模組的互動方式是訊息耦合還是介面耦合。需求大概這樣，我們需要封裝一套客戶端sdk,暴露一系列api給外部用，而這套sdk內部會有很多模組組成，這些模組之間相互會有互...