宣告：本文部分采用和參考《代碼里的世界觀-通往架構師之路》中內容，可以說是該書中耦合性一章的讀后感，感謝該書的作者余葉老師的無私分享，
1.什么是耦合？
耦合其實就是程式之間的相關性，
程式之間絕對沒有相關性是不可能的，否則也不可能在一個程式中啟動，如下圖：
這是一個Linux中socket TCP編程的程式流程圖，在圖中的TCP服務器端，socket()、bind()介面、listen()介面、accept()介面之間肯定存在著相關（就是要呼叫下一個介面程式必需先呼叫前一個介面），也就是耦合，否則整個TCP服務器端就建立不起來，以及改變了bind()中的傳入的資料，比如埠號，那么接下來的listen()監聽的埠，accept()接收連接的埠也會改變，所以它們之間有很強的相關性，屬于緊耦合，所以耦合就是代碼的相關性，如果還不明白，也沒關系，繼續看下去，相信你會懂的，哈哈，
2.耦合的形式
（1）資料之間耦合
在同一個結構體或者類中，如：
typedef struct Person
{
int age;
char* name;
}Person;
class Person
{
private:
int age_m;
bool namePresent_m;
std::string name_m;
};
在上面的結構體和類中，年齡和名字兩個基本資料單元組合成了一個人資料單元，這兩個資料之間就有了耦合，因為它們互相知道，在一些操作中可能需要互相配合操作，當然這兩種資料耦合性是比較低的，但是namePresnet_m是判斷name_m是否存在的資料，所以這兩個資料之間耦合性就高很多了，
（2）函式之間的耦合性
函式如果在一個類中也會互相存在耦合性，比如下面例子：
Class Person
{
Public:
Int getAge(){return age_m;};
Void setAge_v(int age){age_m = age;};
Std::string getName(){return name;};
Void setName(std::string name){name_m = name;};
Private:
Int age_m;
Std::string name_m;
};
其中的getAge()和setAge_v()介面操作的是同一個資料，能夠互相影響，存在著很明顯的耦合，但是getName()和getAge()兩個介面相關性就不明顯的，但是也會存在耦合性，因為getName()能夠訪問的類中資料，getAge()也能訪問，如果程式員撰寫代碼不注意，也會把在兩個介面中呼叫到了相同資料，互相造成了影響，
除了封裝在一個類中的函式之間有耦合性，外部的函式也會根據業務需要產生耦合，比如剛開始說的網路編程的例子中，socket()、listen()、bind()、accept()之間就產生了很強的耦合，
以及在兩個類中，比如：
Class Fruit
{};
Class Apple:Fruit
{};
Class FruitFactory
{
Public:
Furit* getFruit(){Fruit* fruit_p = new Apple(); return fruit_p; }
};
Class Person
{
Public:
Void eatFruit(Fruit* furit);
};
FruitFactory fruitFactory;
Fruit* fruit = fruitFactory.getFruit();
Person person;
If (fruit != NULL)
{
person.eatFruit(fruit);
}
上面的FruitFactory和Person兩個類之間產生了資料耦合，而getFruit()和eatFruit()兩個介面之間也產生了耦合，
（3）資料與函式之間的耦合
從(2)中的程式也能看出，eatFruit()這個介面和Fruit這個資料產生了耦合，如果不先創建Fruit，那么接下來的eatFruit()操作也沒有意義，如果強制呼叫，甚至可能造成程式崩潰，產生coredump，
上面例子的耦合還是比較明顯的，有一些不明顯的耦合，如下：
Speaker speaker;
speaker.PowerOn() ;
speaker.PlayMusic() ;
表面上是 PlayMusic()對PowerOn()有依賴性，是函式之間的耦合，但背后的原因是 PowerOn()函式讓播放器處于通電狀態:
PowerOn(){
this.isPowerOn = true;
}
//只有通了電，播放器才能正常播放音樂
PlayMusic() {
if(this.isPowerOn)
Play();
}
這兩個函式是通過 this .isPowerOn 這個資料進行溝通的 ， 這本質上還是資料和函式之間的耦合，
3.耦合問答
經常聽到“解耦”這個詞，那是不是耦合都是不好的？
這個要根據代碼的耦合性特點來分析，首先看一下下面幾個問題吧，看完，相信大家也有答案了，
（1）耦合可以消除嗎？
經過上面那么多例子，大家也意思到耦合無處不在，所以是不能消除的，
（2）那既然不能消除，那解耦的意思是什么？
解耦就是降低程式模塊之間的耦合性，
（3）那解耦的目的是什么?
解耦的目的是為了增強一個模塊的可移植性、可復用性，就像人的腎可以移植，但是血管卻移植很難移植，為什么，因為血管這個“模塊”和身體這個“系統”之間的“耦合性”太強，關聯地方太多，移植作業量超大，以及減少模塊與外部模塊的關聯，內部模塊的修改對外部影響比較少，這也和用人的腎移植和血管移植類似，每個器官中都有血管，一旦移植，所有器官都要動，耗時耗力，
那可移植和可復用有什么好處？比如我們用程式在電腦寫出了一個俄羅斯方塊的游戲，后來客戶也要在手機端做這個游戲，這時候就能夠復用電腦端的俄羅斯方塊的游戲策略和邏輯，只需要把界面替換掉就行，業務和策略部分基本不用修改，如果電腦端的游戲界面和業務邏輯的程式“渾然一體”，那幾乎就需要重新翻新一遍，
（4）那所有程式都需要解耦嗎？
不是的，有些時候，我們反而需要增強程式的耦合性，這就是平時說的“高內聚，低耦合”，其中的內聚其實也是耦合，或者說程式的相關性，如下面例子：
在界面上的不同位置要顯示多種不同的圖形，如三角形、正方形等 ，這里所有的資訊濃縮在下面兩個陣列里 ，
一個是 shape 陣列 ： ｛ ”三角形”，”正方形＂，”長方形”，＂菱形”｝ ，
一個是 position 陣列 ： ｛ pointl, point2 , poin口 ， point4 ｝ ，
兩個陣列的元素個數是一樣多的，它們是一對一的關系 ， 比如， 第一個 positio口就是第一個 shape 的位置資訊 ， 那么代碼如下：
for(int i = O; i <count, i++）｛
Draw(shape[i] , position[i]);
}
這樣做方便但不好！它會為以后的修改埋藏隱患 ， 因為兩個陣列元素之間的對應關系，并沒有得到正式承認，這時候就需要增強它們之間的關聯，把隱式的關聯轉成顯式的關聯，如下：
Dictionary die = {“三角形”： pointl,
“正方形”： point2 ,
“長方形”： point3 ,
“菱形” ： point4 } ;
//Draw()函式再也不用擔心會畫錯了
foreach(var item in dic){
. Draw(item.key,item.value);
}
平時編程中使用的結構體和類封裝也是同樣，把一些有關聯的資料和方法組合起來，顯式增強它們之間關聯性，方便使用和移植，
4.怎么解耦？
（1）貫徹面向介面編碼的原則
程式不可能沒有改動的，但是盡量把改動放在一個模塊的內部，介面不要變，就算需要改變，最好使用配接器模式增加一個適配程式，因為介面就是一個程式與外部的關聯處，保持介面不變，就是保持該模塊和外部模塊的耦合性不變，這樣才能保證它的可移植性可重用以及不被外部模塊的修改而影響，
（2）保證一個模塊的可測驗（單元測驗）
如果一個模塊是可以單獨進行單元測驗的，意味著它可以移植到其他程式上，耦合性低，
（3）可以學習一下設計模式的設計思想，
（4）讓模塊對內有完整的邏輯
解耦的根本目的是拆除元素之間不必要的聯系，一個核心原則就是讓每個模塊的邏輯獨立而完整，其中包含兩點，一是對內有完整的邏輯 ， 而所依賴的外部資源盡可能是不變數；二是對外體現的特性也是“不變數”（或者盡可能做到不變數），讓別人可以放心地依賴我，有的函式光明磊落，它和外界資料的溝通僅限于函式的引數和回傳值，那么這種函式給人的感覺可以用兩個字形容：靠譜，它把自己所需要的資料都明確標識在引數串列里，把自己能提供的全集中在回傳值里，如果你需要的某項資料不在引數里，你就會儂賴上別人，因為你多半需要指名道姓地標明某個第三方來特供；同理，如果你提供的資料不全在回傳值和引數里，別人會依賴上你 ，有的函式讓人覺得神秘莫測，規律難尋：它所需要的資料不全部體現在引數串列里，有的隱藏在函式內部，這種不可靠的變數行為很難預測；它的產出也不集中在回傳值，而可能是修改了藏在某個不起眼角落里的資源， 這樣的函式需要人們在使用程序中和它不斷地磨合，才能掌握它的特性，前者使用起來放心，而且是可移植、可復用的，后者使用時需要小心翼翼 ，而且很難移植，
5.耦合優化的例子
實體一
在上面介紹的一個例子：
PowerOn(){
this.isPowerOn = true;
}
//只有通了電，播放器才能正常播放音樂
PlayMusic() {
if(this.isPowerOn)
Play();
}
這里的PowerOn()介面和PlayMusic()介面在同一個類中，isPowerOn變數是內部私有變數，這樣寫法是沒問題，如果isPowerOn是一個全域變數，而PlayMusic()介面中程式相對復雜一些，可能就會在外部呼叫時候忘記了先呼叫PowerOn給isPowerOn設定為true，為了讓PlayMusic()的介面邏輯獨立而完整，就需要顯式給PlayMusic()傳入isPowerOn引數，如PlayMusic(bool isPowerOn)，即使是在一個類中，為了防止在外部呼叫時建議在使用PlayMusic()前添加一個判斷isPowerOn介面，如：
Speaker speaker;
If (speaker.isPowerOn())
{
speaker.PlayMusic();
}
這樣在后來有人修改該部分程式時，知道先通電在播放音樂，
實體二
一個人要讀書 ：
Person person = new Person();
person.ReadBook(book);
//ReadBook 函式里的邏輯如下：
void ReadBook( Book book) {
//要求人看書之前要先戴眼鏡，所以第一步必須是戴眼鏡的動作
WearGlasses(this.MyGlasses) ; //Person類中有一個名為 MyClasses的成員
Read (book) ;
如果這個人沒有眼鏡,this.myGlasses 變數為
null ，直接呼叫person. ReadBook(book）；會出現例外，怎么辦呢？
優化一：通過成員函式注入
于是打個補丁邏輯吧，在 ReadBook 之前先給他配副眼鏡 ：
person.setMyGlasses(new Glasses()); //先為person 配副眼鏡
person.ReadBook(book);
如上，加上了 person.setMyGlasses(new Glasses())；這行代碼,這個 bug 就解決了， 可解決得不夠完美，因為這要求每個程式員都需要記住呼叫 person.ReadBook(book）之前，先給成員賦值：
person.setMyGlasses(new Glasses());
這很容易出問題， 因為 ReadBook是一個 public 函式，使用上不應該有隱式的限定條件，
優化二：通過建構式的注入
我們可以為 Person的建構式添加一個 glasses 引數：
public Person (Glasses glasses) {
this.MyGlasses = glasses ;
}
這樣， 每當程式員去創建一個 Person 的時候，都會被逼著去創建一個 Glasses 物件 ， 程式員再也不用記憶一些額外需求了，這樣邏輯便實作了初步的 自我完善，
當 Person類創建得多了，會發現建構式的注人會帶來如下問題 ： 因為 Person 中的很多其他 函式行為，如吃飯、跑步等，其實并不需要眼鏡，而喜歡讀書的人畢竟是少數，所以person.ReadBook(book）；這句代碼的呼叫次數少得可憐，為了一個偏僻的
ReadBook 函式，就要讓每個Person都必須配一副眼鏡（無論他讀不讀書），這不公平，也對，我們應該讓各自的需求各自解決，
那么，還有更好的方法嗎？ 下面介紹的“優化三”進一步解決了這個問題，
優化三：通過普通成員函式的注入
于是可以進行下一步修改：恢復為最初的無參建構式，并單獨為 ReadBook 函式添加一個glasses引數：
void ReadBook(Book book , Glasses glasses ) (
WearGlasses(glasses);
Read (book);
對該函式的呼叫如下 ：
person.ReadBook(book , new Glasses ());
這樣只有需要讀書的人，才會被配一副眼鏡，實作了資源的精確分配，
可是呢，現在每次讀書時都需要配一副新眼鏡：new Glasses()，還是太浪費了，其實只
需要一副就夠了 ，
優化四：封裝注入
好吧，每次取自己之前的眼鏡最符合現實需求 ：
person.ReadBook(book,person.getMyGlasses()) ;
這又回到了最初的問題：person.getMyGlasses()引數可能為空 ，怎么辦？
干脆讓 person.getMyGlasses()封裝的 get 函式自己去解決這個邏輯吧：
Glasses getMyGlasses(){
if(this.myGlasses==null)
this.myGlasses ＝new Glassess();
return this.myGlasses;
}
//然后回傳到最初的ReadBook代碼，ReadBook里的邏輯是默認取自己的眼鏡
void ReadBook(Book book) {
WearGlasses(this.getMyGlasses()) ;
Read(book);
}
對 ReadBook 函式的呼叫如下 ：
person.ReadBook(book);
這樣每次讀書時，就會復用同一副眼鏡了，也不會影響 person 的其他函式，
嗯，大功告成了，最終的這段ReadBook代碼是最具移植性的，稱得上獨立而完整，
可以看到，從優化一到優化四，繞了一圈，每一步修改都非常小，每一步都是解決－個小問題，可能每一步遇到的新問題是之前并沒有預料到的，優化一到優化三分別是3種依賴注入的手段：屬性注入、建構式注入和普通函式注入，它們并沒有優劣之分，只有應用場合之分，這里我們是用一個案例將它們串起來介紹了，同時大家通過這個小小的例子也可以體會到：寫精益求精的代碼，是需要工匠精神的，讓每一個模塊獨立而完整，其內涵是豐富的
， 它把自己所需要的東西全列在清單上，讓外界提供，自己并不私藏，這意味著和外界的關聯是單向的，這樣每個模塊都變得規規矩矩，容易被使用，如果模塊要被替換，拿掉時也不會和周圍模塊藕斷絲連
，
6.這里有彩蛋
沒有絕對好的程式，了解耦合性只是為了寫出比較好的程式，但是在寫程式中過于執著于耦合性，反而不美，不過，平時撰寫程式時候也要注意和思考，慢慢就能獲得一些“感覺”，也就養成了良好的編程習慣，
寫出好代碼的途徑，一是要有一定的知識積累，多看看書，站在前人的肩膀上，不僅僅是代碼數量積累，二是對代碼進行審計，審計自己代碼找出自己一些不好的代碼撰寫習慣，以后有意識去更改，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/84903.html
標籤：C++