我們的許多設計思想中很多地方都體現了解耦合的思想，這是[b]應對易於變化[/b]的一種很好的解決手段，而在這些手段中最重要的解決方法就是[b]新增中間層[/b]，所謂新增中間層 比如我們常見的面向介面程式設計，其實就是新增了乙個中間的層次，遮蔽掉了一些變化，還有就是我們常用的設計模式，什麼**啊，faceda等等，都是採用了這樣的一種思想。
但是在設計過程中我們要不要對全部的東西都進行解耦呢？
我覺得這需要分情況來看：
如果你需要編寫框架之類的應用，那麼這個時候進行解耦是有必要的，原因有兩個：
1、技術方面的：框架需要進行不斷的更新，可能在很多時候原來設計的一些介面或者類就需要進行名稱的改變，雖然這樣不好，介面按道理來說是一般不應該發生變化了，但是誰一開始也不可能把介面設計的那麼完美，改變一下也是可以原諒的。
2、推廣方面的：現在的框架非常多，競爭也非常激烈，當然要迎合程式設計師和老闆的口味了，畢竟人們都喜歡比較靈活的東西，呵呵
我認為spring就是乙個非常聰明的框架，他不去要求程式設計師必須去做什麼，而是提供多種選擇，將實現方式的選擇權交給程式設計師去做決定，其實這也就無形中把別人對其的議論給化解了，不會被人說成是強迫別人如何做的霸道框架，這一點是做的非常聰明的，再加上對現有其他流行框架的整合，所以能夠披荊斬棘，迅速紅遍大江南北！
而說回來，框架為我們提供的這些方式能起到多大的作用呢？
能夠為我們以後的修改帶來多大的便利（如果我們使用別的框架了）？
我沒有看到太多的便利之處，如果拋棄了這些框架，我們還是需要對許多的部分進行更改，工作量的減少程度並不明顯。
現在ror的流行也證明了這一點，有時候在框架方面太靈活也不見得太好，coc有時候就不錯。
所以說在設計的時候把握乙個度是很難的事情，很多時候我們都陷入了過度設計的怪圈，時間花的不少，成效不大：（
很多地方說的不一定正確，請大家批評~~
耦合，緊耦合，松耦合，解耦
一 耦合 耦合是兩個或多個模組之間的相互關聯。在軟體工程中，兩個模組之間的耦合度越高，維護成本越高。因此，在系統架構的設計過程中，應減少各個模組之間的耦合度，以提高應用的可維護性。二 緊耦合 緊耦合架構本質是client server的模型，如下圖所示 優點是 架構簡單 設計簡單 開發周期短 能夠快...
訊息耦合還是介面耦合
訊息耦合還是介面耦合 最近公司準備開發乙個新產品，需要重新設計一套新的框架，但是就這框架中各模組的通訊方式，大家產生了爭論，主要集中在各模組的互動方式是訊息耦合還是介面耦合。需求大概這樣，我們需要封裝一套客戶端sdk,暴露一系列api給外部用，而這套sdk內部會有很多模組組成，這些模組之間相互會有互...
高度解耦合
有三個類 callback 存放委託，可以在別的方法中傳遞不同引數型別和個數的方法 public delegate void callback public delegate void callback t t arg public delegate void callback x t arg1,x...