這是我的基礎(chǔ)系列的第一部分。

我覺得我們真正需要回到的一個基本問題是如何使用和理解接口的價值。

在C#和Java這樣的語言中，接口是非常常見的，它們的使用比5-10年前要普遍得多。

但我們必須捫心自問的一個問題是，“我們是否正確地使用了它們？““

接口解決了什么問題？

我想讓你花點時間，弄清楚你目前是如何使用接口的。

我想讓你假裝你不知道什么是接口。

準(zhǔn)備好了嗎？

一個接口試圖解決的基本問題是將我們?nèi)绾问褂媚硞€東西與如何實現(xiàn)它分開。

為什么我們要把使用和實現(xiàn)分開？

這樣我們就可以編寫代碼來處理各種不同的職責(zé)實現(xiàn)，而不必專門處理每個實現(xiàn)。

更簡單地說，這意味著如果我們有一個Driver類，它應(yīng)該能夠有一個方法Drive，可以用來驅(qū)動任何汽車、船或其他實現(xiàn)IDriveable接口的類。

Driver類不必為每一類都提供DriveBoat、DriveCar或DriveX方法，這些類支持驅(qū)動所需的相同基本操作。

接口試圖解決一個非常具體的問題，允許我們根據(jù)對象的行為而不是如何與對象交互。

接口是合同

接口允許我們指定特定類滿足其他類可以依賴的特定期望。

如果我們有一個實現(xiàn)接口的類，我們可以確定它將支持該接口中定義的所有方法。

乍一看，接口似乎類似于具體的繼承，但有一個關(guān)鍵的區(qū)別。

具體的繼承說Car是一輛汽車，而接口說Car實現(xiàn)了可驅(qū)動的接口。

當(dāng)類實現(xiàn)一個接口時，并不意味著類就是那個接口。因此，完全描述類功能的接口通常是錯誤的。

一個類可以實現(xiàn)多個接口，因為每個接口只討論該類能夠?qū)崿F(xiàn)的特定契約。

接口總是由多個類實現(xiàn)的

你可能會說“不，它們不是，我這里有一個類，它有一個其他類都沒有實現(xiàn)的接口?！?/span>對此我說，“你做錯了?！?/span>但是，別擔(dān)心，不止你一個人。我也做錯了。我們中的許多人不再正確地使用接口，而是使用它們，因為我們的印象是，我們永遠不應(yīng)該直接使用具體的類。

我們害怕應(yīng)用程序之間的緊密耦合，所以不管是否需要接口，我們都會為每個類創(chuàng)建接口。

我之所以說接口總是由多個類實現(xiàn)，有一些非常好的理由。

還記得我們說過如何設(shè)計接口來解決特定問題嗎？

在我的示例中，我討論了Driver類不必擁有它可以驅(qū)動的每種類的方法，而是應(yīng)該依賴于IDrivable接口，并擁有一個通用的drive方法來驅(qū)動實現(xiàn)IDrivable的任何東西。

我們大多數(shù)人都接受YAGNI原則，即“你不會需要它。”如果我們只有一個Car類，而沒有任何其他類需要由司機類驅(qū)動，我們就不需要接口。

在某個時候，我們可能會添加一個Boat類。只有在那個時候，我們才真正有了一個接口將要解決的問題。直到那個時候，添加接口是預(yù)期未來要解決的問題。

如果你認為自己擅長預(yù)測何時需要接口，我希望你做一個小練習(xí)。進入你的代碼庫，數(shù)一數(shù)你擁有的所有接口。然后數(shù)一數(shù)實現(xiàn)這些接口的所有類。我敢打賭這個比率非常接近1:1。

但我該怎么測試呢？如何使用依賴注入？

這兩個原因可能是錯誤使用接口的最合理的原因。

我為創(chuàng)建一個接口而感到內(nèi)疚，這樣我就可以模擬一些東西，我也為我的依賴注入框架創(chuàng)建一個接口而感到內(nèi)疚，但這并不能使它正確。

在這里，我不能簡單地回答您，并且說我可以在沒有接口的情況下解決您的單元測試或依賴項注入問題，但是我可以談?wù)劄槭裁次覀儾粦?yīng)該彎曲源代碼來適應(yīng)工具或方法。

我之前談到過單元測試的目的，其中一個關(guān)鍵的好處是單元測試有助于指導(dǎo)您的設(shè)計。單元測試可以幫助我們分離應(yīng)用程序，并將類整合到單個職責(zé)中，這使得嘗試和單元測試具有多個依賴項的類非常痛苦。

接口是一種快捷方式，它允許我們擺脫類中的大量依賴關(guān)系。

當(dāng)我們把一個具體類的引用變成一個接口引用時，我們在欺騙系統(tǒng)。我們假裝我們的類是解耦的，因為它引用的是一個接口而不是一個具體的類，從而使編寫單元測試變得更容易。實際上，它并沒有解耦，它實際上更耦合，因為我們的類耦合到一個接口，而這個接口耦合到一個類。我們所做的只是添加間接級別。

依賴注入促進了同樣的接口濫用問題。至少它現(xiàn)在在C#和Java中的使用方式是這樣的。創(chuàng)建一個接口僅僅是為了能夠?qū)⒃摻涌诘奈ㄒ粚崿F(xiàn)注入到類中，這會產(chǎn)生不必要的間接級別，并且不必要地降低類的性能我們的申請。

別誤會。依賴注入很好。我會把細節(jié)留到另一篇文章中，但我相信依賴注入的真正好處是當(dāng)它用于控制使用哪個接口實現(xiàn)時，而不是當(dāng)一個接口只有一個實現(xiàn)時。

歸根結(jié)底，我無法給你一個好的答案，即如何在不濫用接口的情況下進行單元測試或使用依賴注入。我認為你可以通過選擇拆分類并實際減少依賴性來減少濫用，而不是簡單地創(chuàng)建一個接口并將其注入類中，但你仍然會遇到問題一輛車有一個引擎，如果你想單元測試這輛車，你要么要用真正的引擎，要么想辦法模仿它。

這里的關(guān)鍵問題是接口是語言的一部分，但是單元測試和依賴注入不是。我們正試圖通過使用技巧使它們與語言相適應(yīng)。技巧是我們創(chuàng)建一個接口來提供類之間的接縫。問題是我們這樣做稀釋了接口的效力。我們真正需要的是一個語言支持的接縫，讓我們能夠輕松地替換具體類在運行時的實現(xiàn)。