[[281621]]

好的系統(tǒng)架構(gòu)離不開好的接口設(shè)計，因此，真正懂接口設(shè)計的人往往是軟件設(shè)計隊伍中的稀缺型人才。

為什么在接口制定標準中說：一流的企業(yè)做標準，二流的企業(yè)做品牌，三流的企業(yè)做產(chǎn)品?依賴倒置到底是什么意思?什么時候使用接口才算合理?今天，阿里匠人——張建飛將為你詳細解讀。

接口有什么好處(Why)

在我看來，接口在軟件設(shè)計中主要有兩大好處：

1. 制定標準

標準規(guī)范的制定離不開接口，制定標準的目的就是為了讓定義和實現(xiàn)分離，而接口作為完全的抽象，是標準制定的不二之選。

這個世界的運轉(zhuǎn)離不開分工協(xié)作，而分工協(xié)作的前提就是標準化。試想一下，你家的電腦能允許你把顯卡從NVIDIA換成七彩虹;你家的燈泡壞了，你可以隨便找一個超市買一個新的就可以換上;你把數(shù)據(jù)從Oracle換成了MySQL，但是你基于JDBC寫的代碼都不用動。等等這些事情的背后都是因為接口，以及基于接口定制的標準化在起作用。

在Java的世界里，有一個很NB的社區(qū)叫JCP( Java Community Process)，就是專門通過JSR(Java Specification Request)來制定標準的。正是有了JSR-315(Java Servlet)，我們服務端的代碼才能在Tomcat和Jetty之間自由切換。

最后，我想用一句話來總結(jié)一下標準的重要性，那就是：“一流的企業(yè)做標準，二流的企業(yè)做品牌，三流的企業(yè)做產(chǎn)品。

2. 提供抽象

除了標準之外，接口還有一個特征就是抽象。正是這樣的抽象，得以讓接口的調(diào)用者和實現(xiàn)者可以完全的解耦。

解耦的好處是調(diào)用者不需要依賴具體的實現(xiàn)，這樣也就不用關(guān)心實現(xiàn)的細節(jié)。這樣，不管是實現(xiàn)細節(jié)的改動，還是替換新的實現(xiàn)，對于調(diào)用者來說都是透明的。

這種擴展性和靈活性，是軟件設(shè)計中，最美妙的設(shè)計藝術(shù)之一。一旦你品嘗過這種“依賴接口”的設(shè)計來帶的美好，就不大會再愿意回到“依賴實現(xiàn)”的簡單粗暴。平時我們說的“面向接口編程原則”和“依賴倒置原則”說的都是這種設(shè)計。

另外，一旦你融會貫通的掌握了這個強大的技巧——面向抽象、面向接口，你會發(fā)現(xiàn)，雖然面向?qū)崿F(xiàn)和面向接口在代碼層面的差異不大，但是其背后所隱含的設(shè)計思想和設(shè)計理念的差異，不亞于我籃球水平和詹姆斯籃球水平之間的差異!

//面向接口 
    Animal dog = new Dog(); 
 
    //面向?qū)崿F(xiàn) 
    Dog dog = new Dog(); 

作為一名資深職場老兵，我墻裂建議各位在做系統(tǒng)設(shè)計、模塊設(shè)計、甚至對象設(shè)計的時候。要多考慮考慮更高層次的抽象——也就是接口，而不是一上來就陷入到實現(xiàn)的細節(jié)中去。要清楚的意識到接口設(shè)計是我們系統(tǒng)設(shè)計中的主要工作內(nèi)容。而這種可以跳出細節(jié)內(nèi)容，站在更高抽象層次上，來看整個系統(tǒng)的模塊設(shè)計、模塊劃分、模塊交互的人，正是我們軟件設(shè)計隊伍中，非常稀缺的人才。有時候，我們也管這些人叫架構(gòu)師。

什么時候要用接口(When)

有擴展性需求的時候

可擴展設(shè)計，主要是利用了面向?qū)ο蟮亩鄳B(tài)特性，所以這里的接口是一個廣義的概念，如果用編程語言的術(shù)語來說，它既可以是Interface，也可能是Abstract Class。

這種擴展性的訴求在軟件工作中可以說無處不在，小到一個工具類。例如，我現(xiàn)在系統(tǒng)中需要一個開關(guān)的功能，開關(guān)的配置目前是用數(shù)據(jù)庫做配置的，但是后續(xù)可能會遷移到Diamond配置中心，或者SwitchCenter上去。

簡單做法就是，我直接用數(shù)據(jù)庫的配置去實現(xiàn)開關(guān)功能，如下圖所示：

但是這樣做的問題很明顯，當需要切換新的配置實現(xiàn)的話，就不得不扒開原來的應用代碼做修改了。更恰當?shù)淖龇☉撌翘峁┮粋€Switch的接口，讓不同的實現(xiàn)去實現(xiàn)這個接口，從而在切換配置實現(xiàn)的時候，應用代碼不再需要更改了。

如果說，上面的重構(gòu)只是使用策略模式對代碼進行了局部優(yōu)化，做了當然更好，不做的話，影響也還好，可以將就著過。

那么接下來我要給大家介紹的場景，就不僅僅是“要不要”的問題，而是“不得不”的問題了。

例如，老板給你布置了一個任務，實現(xiàn)一個類似于eclipse可以可插拔(Pluggable)的產(chǎn)品，此時，使用接口就不僅僅是一個選擇問題了，而是你不得不使用的架構(gòu)方法了。因為，可插拔的本質(zhì)就是，你制定一個標準接口(API)，然后有不同的實現(xiàn)者去做插件的實現(xiàn)，最后再由PluginManager把這個插件機制串起來而已。

下圖是我當時給ICBU設(shè)計的一個企業(yè)協(xié)同云的Pluggable架構(gòu)，其本質(zhì)上，也就是基于接口的一種標準和擴展的設(shè)計。

需要解耦的時候

上面介紹的關(guān)于Switch的例子，從表面上來看，是擴展性的訴求。但不可擴展的本質(zhì)原因正是因為耦合性。當我們通過Switch Interface來解開耦合之后，擴展性的訴求也就迎刃而解了。

發(fā)現(xiàn)這種耦合性，對系統(tǒng)的可維護性至關(guān)重要。有一些耦合比較明顯(比如Switch的例子)。但更多的耦合是隱式的，并沒有那么明顯，而且在很長一段時間，它也不是什么問題，但是，一旦它變成一個問題，將是一個非常頭痛的問題。

一個真實的典型案例，就是java的logger，早些年，大家使用commons-logging、log4j并沒有什么問題。然而，此處一個隱患正在生長——那就是對logger實現(xiàn)的強耦合。

當logback出來之后，事情開始變得復雜，當我們想替換一個新的logger vendor的時候，為了盡量減少代碼改動，不得不上各種Bridge(橋接)，到最后日志代碼變成了誰也看不懂的代碼迷宮。下圖就是我費了九頭二虎之力，才梳理清楚的一個老業(yè)務系統(tǒng)的日志框架依賴情況。

試想一下，假如一開始我們就能遇見到這種緊耦合帶來的問題。在應用和日志框架之間加入一層抽象解耦。后續(xù)的那么多橋接，那么多的向后兼容都是可以省掉的麻煩。而我們所要做的事情，實際上也很簡單——就是加一個接口做解耦而已(如下圖所示)：

要給外界提供API的時候

上文已經(jīng)介紹過JCP和JSR了，大家有空可以去閱讀一些JSR的文檔。不管是做的比較成功的JSR-221(JDBC規(guī)范)、JSR-315(Servlet規(guī)范)，還是比較失敗的JSR-94(規(guī)則引擎規(guī)范)等等。其本質(zhì)上都是在定義標準、和制定API。其規(guī)范的內(nèi)容都是抽象的，其對外發(fā)布的形式都是接口，它不提供實現(xiàn)，最多會指導實現(xiàn)。

還有就是我們通常使用的各種開放平臺的SDK，或者分布式服務中RPC的二方庫，其包含的主要成分也是接口，其實現(xiàn)不在本地，而是在遠程服務提供方。

類似于這種API的情況，都是在倒逼開發(fā)者要把接口想清楚。我想，這也算微服務架構(gòu)一個漂亮的“副作用”吧。當原來單體應用里的各種耦合的業(yè)務模塊，一旦被服務化之后，就自然而然的變成“面向接口”的了。

通過依賴倒置來實現(xiàn)面向接口(How)

關(guān)于依賴倒置，我以前寫過不少文章，來闡述它的重要性。實際上，我上面給出的關(guān)于擴展需求的Switch案例，關(guān)于解耦的logger案例。其背后用來解決問題的方法論都是依賴倒置。

如上圖所示，依賴倒置原則主要規(guī)定了兩件事情：

1. 高層模塊不應該依賴底層模塊，兩者都應該依賴抽象(如上面的圖2所示)

2. 抽象不應該依賴細節(jié)，細節(jié)應該依賴抽象。

我們回頭看一下，不管是Switch的設(shè)計，還是抽象Logger的設(shè)計，是不是都在遵循上面的兩條定義內(nèi)容呢。

實際上，DIP(依賴倒置原則)不光在對象設(shè)計，模塊設(shè)計的時候有用。在架構(gòu)設(shè)計的時候也非常有用，比如，我在做COLA 1.0的時候，和大多數(shù)應用架構(gòu)分層設(shè)計一樣，默許了Domain層可以依賴Infrastructure層。

這種看起來“無傷大雅”的設(shè)計，實際上還是存在不小的隱患，也違背了我當初想把業(yè)務復雜度和技術(shù)復雜度分開的初心，當業(yè)務變得更加復雜的時候，這種“偷懶”行為很可能會導致Domain層墮落成大泥球(Big mud ball)。因此，在COLA 2.0的時候，我決定用DIP來反轉(zhuǎn)Domain層和Infrastructure層的關(guān)系，最終形成如下的結(jié)構(gòu)：

這樣做的好處是Domain層會變得更加純粹，其好處體現(xiàn)在以下三點：

1、解耦： Domain層完全擺脫了對技術(shù)細節(jié)(以及技術(shù)細節(jié)帶來的復雜度)的依賴，只需要安心處理業(yè)務邏輯就好了。

2、并行開發(fā)： 只要在Domain和Infrastructure約定好接口，可以有兩個同學并行編寫Domain和Infrastructure的代碼。3、可測試性： 沒有任何依賴的Domain里面都是POJO的類，單元測試將會變得非常方便，也非常適合TDD的開發(fā)。

什么時候不需要接口

"勁酒雖好，可不要貪杯哦!"

和許多其它軟件原則一樣，面向接口很好，但也不應該是不分背景、不分場合胡亂使用的殺手锏和尚方寶劍。因為過多的使用接口，過多的引入間接層也會帶來一些不必要的復雜度。

比如，我就看過有些應用的內(nèi)部模塊設(shè)計的過于“靈活”，給什么DAO、Convertor都加上一層Interface，但實際情況是，應用中對DAO、Convertor的實現(xiàn)進行替換的可能性極低。類似于這樣的，裝模作樣，裝腔作勢的Interface就屬于可有可無的雞骨頭(比雞肋還低一個檔次)。

就像《Effective Java》的作者Joshua Bloch所說：

“同大多數(shù)學科一樣，學習編程的藝術(shù)首先要學會基本的規(guī)則，然后才能知道什么時候可以打破這些規(guī)則。”