過關斬將之資訊科技怎麼安裝

什麼是IOC？

什麼是DI？

IOC和DI有什麼關係？

作為程式設計師，天天擼程式碼，怎麼能不知道

IOC

和DI呢。很多面試官也喜歡問這兩個概念，雖然概念很簡單，但是可以從面試者的回答當中，大體的可以估算到面試者的功力，那IOC和DI到底是何方神聖呢？讓我們來一步一步扒掉它的外衣！！

說到IOC和DI，必須要提一下軟體設計的六大原則

單一職責原則

一個類應該只有一個發生變化的原因

開閉原則

軟體實體應該是可擴充套件，而不可修改的。也就是說，對擴充套件是開放的，而對修改是封閉的。這個原則是諸多面向物件程式設計原則中最抽象、最難理解的一個。

里氏替換原則

所有引用基類的地方必須能透明地使用其子類的物件，換句話說，子類在任何引用基類的地方都可以替換成子類。

依賴倒置原則

這個原則說的詳細一點其實可以概括為兩點：

高層模組不應該直接依賴於底層模組，應該依賴於抽象

抽象不應該依賴於具體實現，具體實現應該依賴於抽象

介面隔離原則

程式不依賴於不使用的介面，換句話說，一個程式只依賴於它需要的介面。

我在之前的很多文章中也多次提到，要想系統保持高擴充套件性，始終離不開對業務的深刻理解和抽象

論系統設計的高可擴充套件性

IOC

控制反轉（Inversion of Control，縮寫為IoC），是面向物件程式設計中的一種設計原則，可以用來減低計算機程式碼之間的耦合度

以上是IOC最典型的概念定義，其中“控制”這個詞具有很泛的概念，比如：控制物件的初始化，控制程式的流程，控制資源的生命週期。。。等等，反轉就和表面意思一樣比較好理解，就是反過來。控制和反轉綜合起來呢，可以概括為：

對於程式的行為，把控制權交給其他人

確實不好理解，因為上面這句話是我自己總結的，說實話，我自己咋一聽到都理解不了。還是舉個栗子吧：

最常見並且最常用的莫過於類的使用，如下程式碼：

class A

{

public void XXOO{

}

}

class Main

{

A a=new A；

a。XXOO；

}

上面的程式碼我想在我們平時的coding過程中非常多，那有什麼問題嗎？還是那句話，從功能性的角度來說，只存在正確和錯誤的觀點，但是從非功能性的角度來說，每個人有每個人的見解。有的人不喜歡程式碼中中到處充斥著New的味道，有的人卻喜歡掌控自己的程式碼（因為自己寫的New，自己最清楚）。

至於軟體編寫的對與錯，並沒有一個明確的規範去說明，但是軟體從小到大，從簡單需求到越來越多的需求，把軟體開發過程中一些不爽的詬病提取出來並解決，就是軟體質量提升的一個度量角度。

言歸正傳，上面的程式碼以多數程式設計師的角度來說，不喜歡到處有New這個關鍵字，就好像New多了會出Bug一樣！！為什麼好多架構師不推薦到處有New的味道？我認為並不是程式碼美不美觀，能不能裝X的問題，是因為軟體架構層次中強依賴的關係。

那怎麼破除強依賴呢？

DI（依賴注入）

與IOC不同，DI是一種具體的編碼技巧。但是，它並非為了解決New的問題而生，而是為了解決軟體架構層面的問題而生，其實，從大多數使用場景來說，DI確實可以看做是實現IOC的一種解決方案。

有的架構師說，依賴注入就是把類放到容器當中，然後解析這些類的例項。我不否認原理上確實是容器來負責管理有依賴關係的模組或者類（介面），但是依賴注入在依賴關係上其實在為了解耦和多型。

說到這裡，突然想起一件小事，作為高大上工作的開發者，都已經跨入21世界20多個年頭了，還在圍繞著資料庫進行coding，在沒有表的情況下居然沒辦法開展工作？我並不排斥圍繞資料庫進行設計編碼，因為很多統計類的需求確實需要這樣，但是大多數業務不應該是圍繞業務來開展編碼嗎？沒有資料庫就不能進行coding是不是該改一改了？

依賴注入會在架構的擴充套件點出現，一個好的軟體架構，永遠會在需要擴充套件的地方提供自定義入口，說直白一點，任何一個系統都應該在會變化的地方進行抽象。舉一個簡單例子：一個支付系統會存在多種支付方式：微信、支付寶、銀聯等等。這些不同的支付方式其實就可以看做是系統的變化點，應該把這個地方進行抽象，並花大量精力去好好設計。

重點問題

那麼問題來了：如果我沒有使用面向介面（interface）進行開發，程式碼的分層一律都是以類（Class）來組織的，類似於以下程式碼：

var ret = await UserService。SetDefaultUserPlan（para。UserId， para。UserPlanId）；

那我的類UserService是否也應該進行依賴注入呢？類似於以下程式碼（DI框架可能不一樣，但是原理都是相同的）

services。AddSingleton；

我想這個問題，每個人也都有自己的見解。有很多人認為，DI解決的是到處充斥著New味道的問題，每個類都應該進行DI操作，這樣的程式碼才夠“簡潔，漂亮”。

是嗎？

針對於以上觀點，我其實有話要說。還是本質問題的討論，DI到底要解決軟體開發中的什麼問題呢？是New的問題嗎？不，是解耦、擴充套件、依賴的問題。

說道這三個非功能性的指標，其實和上邊講的幾大軟體設計規則息息相關，無論是什麼樣的軟體系統都擺脫不了業務變化的命運。有的程式設計師最害怕這種變化，因為一旦發生業務變化，他就要改動大量的程式碼，接連會產生大量的Bug，進而會加大量的班。

其實，面對變化的時候，如果發生以上情況，我們應該反思自己是不是沒有把業務的變化點分析清楚。還是拿支付業務為例，假如系統開始只有微信支付，可能你的程式碼很像以下這種

public void Pay（int amount）

{

//微信支付

WXPay。Pay（amount）；

}

隨著時間推移，公司業務發展壯大，產品上要支援支付寶支付，你的程式碼很大機率會變成這樣

public void Pay（int payMode， int amount）

{

if （payMode == “微信支付”）

{

//微信支付

WXPay。Pay（amount）；

}

else if （payMode == “支付寶支付”）

{

//支付寶支付

AliPay。Pay（amout）；

}

}

如果隨著業務繼續發展，產品上又陸續加入了很多支付方式，你的程式碼就會變成以下這種方式

public void Pay（int payMode， int amount）

{

if （payMode == “微信支付”）

{

//微信支付

WXPay。Pay（amount）；

}

else if （payMode == “支付寶支付”）

{

//支付寶支付

AliPay。Pay（amout）；

}

else if （payMode == “XX支付”）

{

//支付寶支付

XXXPay。Pay（amout）；

}

else if （payMode == “YY支付”）

{

//支付寶支付

YYPay。Pay（amout）；

}

。

。

。

}

大量的if-else，很多人稱之為“壞程式碼”味道（其實這樣的程式碼每個公司都有）。透過這個例子其實大家已經看出來了，支付方式這是一個業務的變化點，應該在這個業務點上做抽象了。這個時候所謂的面向介面程式設計正是解決之道，其實也可以理解為程式的多型性：

interface IPay

{

void Pay（int amount）；

}

然後每次新加一種支付方式，去實現這個介面，然後利用DI操作一下。在業務發生變化的過程中，根據某種策略來實現對應的支付方式即可。

在這個例子中，利用DI技術不僅解決了依賴倒置原則，更解決了系統擴充套件性的問題。回到開頭的問題，為了解決New的美觀問題，到底應不應該使用DI呢？其實我不推薦

寫在最後

關於上邊的問題，歡迎來噴，畢竟知識需要討論才能進步

挺帶勁！透過 Nginx 來實現封殺惡意訪問

如何給妹子最佳化 Windows ？