【Spring】程序的耦合和解耦，spring IoC 的概念以及原理
1. 程序的耦合和解耦
1.1 什麼是程序的耦合
- 耦合性(Coupling)，也叫耦合度，是對模塊間關聯程度的度量。耦合的強弱取決於模塊間接口的複雜性、調用模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關係，包括控制關係、調用關係、數據傳遞關係。模塊間聯繫越多，其耦合性越強，同時表明其獨立性越差( 降低耦合性，可以提高其獨立性)。 耦合性存在於各個領域，而非軟件設計中獨有的，但是我們只討論軟件工程中的耦合。
在軟件工程中， 耦合指的就是就是對象之間的依賴性。對象之間的耦合越高，維護成本越高。因此對象的設計應使類和構件之間的耦合最小。 軟件設計中通常用耦合度和內聚度作爲衡量模塊獨立程度的標準。 劃分模塊的一個準則就是高內聚低耦合。
- 它有如下分類：
- 內容耦合。當一個模塊直接修改或操作另一個模塊的數據時，或一個模塊不通過正常入口而轉入另一個模塊時，這樣的耦合被稱爲內容耦合。內容耦合是最高程度的耦合，應該避免使用之。
- 公共耦合。兩個或兩個以上的模塊共同引用一個全局數據項，這種耦合被稱爲公共耦合。在具有大量公共耦合的結構中，確定究竟是哪個模塊給全局變量賦了一個特定的值是十分困難的。
- 外部耦合 。一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳
遞該全局變量的信息，則稱之爲外部耦合。 - 控制耦合 。一個模塊通過接口向另一個模塊傳遞一個控制信號，接受信號的模塊根據信號值而進
行適當的動作，這種耦合被稱爲控制耦合。 - 標記耦合 。若一個模塊 A 通過接口向兩個模塊 B 和 C 傳遞一個公共參數，那麼稱模塊 B 和 C 之間存在一個標記耦合。
- 數據耦合。模塊之間通過參數來傳遞數據，那麼被稱爲數據耦合。數據耦合是最低的一種耦合形式，系統中一般都存在這種類型的耦合，因爲爲了完成一些有意義的功能，往往需要將某些模塊的輸出數據作爲另一些模塊的輸入數據。
- 非直接耦合 。兩個模塊之間沒有直接關係，它們之間的聯繫完全是通過主模塊的控制和調用來實現的。
-
總結：
耦合是影響軟件複雜程度和設計質量的一個重要因素，在設計上我們應採用以下原則：如果模塊間必須存在耦合，就儘量使用數據耦合，少用控制耦合，限制公共耦合的範圍，儘量避免使用內容耦合。 -
內聚與耦合
內聚標誌一個模塊內各個元素彼此結合的緊密程度，它是信息隱蔽和局部化概念的自然擴展。 內聚是從功能角度來度量模塊內的聯繫，一個好的內聚模塊應當恰好做一件事。它描述的是模塊內的功能聯繫。耦合是軟件結構中各模塊之間相互連接的一種度量，耦合強弱取決於模塊間接口的複雜程度、進入或訪問一個模塊的點以及通過接口的數據。 程序講究的是低耦合，高內聚。就是同一個模塊內的各個元素之間要高度緊密，但是各個模塊之間的相互依存度卻要不那麼緊密。
內聚和耦合是密切相關的，同其他模塊存在高耦合的模塊意味着低內聚，而高內聚的模塊意味着該模塊同其他模塊之間是低耦合。在進行軟件設計時，應力爭做到高內聚，低耦合。
1.2 解決程序耦合的思路
我們在開發中，有些依賴關係是必須的，有些依賴關係可以通過優化代碼來解除的。
請看下面的示例代碼：
public class AccountServiceImpl implements IAccountService {
private IAccountDao accountDao = new AccountDaoImpl();
}
上面的代碼表示：
業務層調用持久層，並且此時業務層在依賴持久層的接口和實現類。如果此時沒有持久層實現類，編譯將不能通過。 這種編譯期依賴關係，應該在我們開發中杜絕。 我們需要優化代碼解決。
再比如：
早期我們的 JDBC 操作，註冊驅動時，我們爲什麼不使用 DriverManager 的 register 方法，而是採用 Class.forName 的方式？
package com.siyi.jdbc;
import java.sql.*;
public class JdbcDemo1 {
public static void main(String[] args) throws SQLException, ClassNotFoundException {
//註冊驅動
// DriverManager.registerDriver(new com.mysql.jdbc.Driver());
Class.forName("com.mysql.jdbc.Driver");
//獲取連接
Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/spring_demo","root","root");
//獲取操作數據庫的預處理對象
PreparedStatement ps = conn.prepareStatement("select * from account");
//執行sql,得到結果集
ResultSet resultSet = ps.executeQuery();
//遍歷結果集
while(resultSet.next()){
System.out.println(resultSet.getString("name"));
}
//釋放資源
resultSet.close();
ps.close();
conn.close();
}
}
原因就是：
我們的類依賴了數據庫的具體驅動類（MySQL） ，如果這時候更換了數據庫品牌（比如 Oracle） ，需要修改源碼來重新數據庫驅動。這顯然不是我們想要的。
當是我們講解 jdbc 時，是通過反射來註冊驅動的，代碼如下：
Class.forName("com.mysql.jdbc.Driver");//此處只是一個字符串
此時的好處是，我們的類中不再依賴具體的驅動類，此時就算刪除 mysql 的驅動 jar 包，依然可以編譯（運行就不要想了，沒有驅動不可能運行成功的） 。
同時，也產生了一個新的問題， mysql 驅動的全限定類名字符串是在 java 類中寫死的，一旦要改還是要修改源碼。
解決這個問題也很簡單，使用配置文件配置。
1.3 工廠模式解耦
在實際開發中我們可以把三層的對象都使用配置文件配置起來，當啓動服務器應用加載的時候， 讓一個類中的方法通過讀取配置文件，把這些對象創建出來並存起來。在接下來的使用的時候，直接拿過來用就好了。
那麼，這個讀取配置文件， 創建和獲取三層對象的類就是工廠。
2. 什麼是IoC
IOC是Inversion of Control的縮寫，多數書籍翻譯成“控制反轉”，還有些書籍翻譯成爲“控制反向”或者“控制倒置”。
以前我們寫的程序固然功能實現了，但是並不靈活，很多地方都是寫死了的。
程序之間的耦合性太高，開發效率低下。
1996年，Michael Mattson在一篇有關探討面向對象框架的文章中，首先提出了IOC這個概念。簡單來說就是把複雜系統分解成相互作用合作的對象，這些對象類通過封裝以後，內部實現對外部是透明的，從而降低了解決問題的複雜度，而且可以靈活地被重用和擴展.IOC理論提出的觀點大體是這樣的：藉助於“第三方”實現具有依賴關係的對象之間的，如下圖：
由上圖我們很容易看出對象A,B,C,D的齒輪轉動（運行）都是依靠第三方，也就是IoC容器。全部對象的控制權全部上繳給“第三方” IOC容器，所以，IOC容器成了整個系統的關鍵核心，它起到了一種類似“粘合劑”的作用，把系統中的所有對象粘合在一起發揮作用，如果沒有這個“粘合劑”，對象與對象之間會彼此失去聯繫，這就是有人把IOC容器比喻成“粘合劑”的由來。
如果我們把IoC容器拿掉呢？
這時候我們發現A，B，C，D這4個對象之間已經沒有了耦合關係，彼此毫無聯繫，這樣的話，當你在實現A的時候，根本無須再去考慮B，C和D了，對象之間的依賴關係已經降低到了最低程度。所以，如果使用IOC容器，對於開發而言，這將是一件多麼美好的事情，參與開發的每一成員只要實現自己的類就可以了。不需要怕被別人實現的影響。
- IoC名字的由來
軟件系統在沒有引入IOC容器之前，如圖1所示，對象A依賴於對象B，那麼對象A在初始化或者運行到某一點的時候，自己必須主動去創建對象B或者使用已經創建的對象B.無論是創建還是使用對象B，控制權都在自己手上。
軟件系統在引入IOC容器之後，這種情形就完全改變了，如圖2所示，由於IOC容器的加入，對象A與對象B之間失去了直接聯繫，所以，當對象A運行到需要對象B的時候，IOC容器會主動創建一個對象B注入到對象A需要的地方。
通過前後的對比，我們不難看出來：對象A獲得依賴對象B的過程，由主動行爲變爲了被動行爲，控制權顛倒過來了，這就是“控制反轉”這個名稱的由來。