一、為什麼專案中需要使用介面？

在專案中，有一些功能，不僅僅是一個類去實現，即有很多地方有用到，大家需要統一標準。所以需要用介面，這樣大家同時實現一個介面，就能夠統一規範。在介面中只是定義了基本的方法名，具體的實現交給實現類。

統一標準之後的下一件事情，就是多型。多型的實現，是使用了動態繫結技術，這裡不做進一步展開。只需要知道在C和C++中，是前期繫結，也就是在編譯前，就已經知道了具體執行哪些程式碼；而在java中，是後期繫結或者說是動態繫結，也就是在程式執行的那一刻，才會知道執行什麼程式碼。而動態繫結技術，是實現多型的重要條件。

統一標準後，父類宣告，子類例項化，呼叫介面方法，就可以產生不同的結果。比如手機和電視都實現了播放功能。這個時候：

Usb u1=new Phone();
Usb u2=new Tv();
u2.play();

這個時候控制檯輸出的就是不同的語句了，u1輸出手機播放的方法，u2輸出電視的播放方法。

我們來想一想，這樣做有什麼好處？

1.程式碼簡潔

如果我有100個播放裝置，那麼只要繼承Usb介面，實現play（）方法，並且按照上述的方式去呼叫，就可以得到不同的效果；如果我們不實現介面，而是僅僅在類裡面自己寫play方法，那麼我們呼叫的時候就需要指名具體是哪一個類，而程式執行的時候如果不能明確寫明是哪一個類，處理起來就非常麻煩。

2.實現可以多種多樣&維護成本低

再比如，有一個叫comparable的介面。數字可以比較，那麼自定義的類怎麼比較呢？實現了介面，我們就可以用實現類去例項化父類的comparable介面，直接呼叫compareTo方法比較即可（正面）；如果我們不用，那麼在寫程式碼的時候就要自己記住去寫compareTo方法，並且呼叫的時候，直接指定清楚類名。並且，如果有100個類都需要比較，人會犯錯，可能別人寫的不是compareTo方法，而是改了個名字，可能別人比較不再是規定好的返回boolean型別的結果，可能。。。。這樣就給程式碼的迭代、維護帶來很高的成本。

3.降低程式碼的耦合性

假設張三、李四同時開發一個模組。張三負責寫收銀員類和方法，李四負責寫計算器類和方法。如果沒有介面，那麼張三寫好了之後，需要呼叫李四的方法，想當然的認為方法名是jisuan（），結果卻發現李四的方法名是countMoney（），這個時候就需要去修改程式碼了，帶來了不必要的麻煩（反面）。

如果在工作剛剛開始的時候，張三提前想到了這一步，規定了，李四，你寫計算器類的時候，需要實現我的Icount介面，介面中規定了你需要實現一個計算的方法，按照我的方法名，和返回型別，返回給我正確的方法，我直接在我的程式碼中呼叫即可。

綜上所述，介面是有很多好處的。接下來，我們應該如何理解介面呢？

二、介面的理解

1.介面就是個招牌

比如說你今年放假出去杭州旅遊，玩了一上午，你也有點餓了，突然看到前面有個店子，上面掛著KFC，然後你就知道今天中飯有著落了。

KFC就是介面，我們看到了這個介面，就知道這個店會賣炸雞腿（實現介面）。
那麼為什麼我們要去定義一個介面呢？這個店可以直接賣炸雞腿啊（直接寫實現方法），是的，這個店可以直接賣炸雞腿，但沒有掛KFC的招牌，我們就不能直接簡單粗暴的衝進去叫服務員給兩個炸雞腿了。

要麼，我們就要進去問，你這裡賣不賣炸雞腿啊，賣不賣漢堡啊，賣不賣聖代啊（這就是反射）。很顯然，這樣一家家的問實在是非常麻煩（反射效能很差）。
要麼，我們就要記住，中山路108號賣炸雞，黃山路45號賣炸雞（硬編碼），很顯然這樣我們要記住的很多很多東西（程式碼量劇增），而且，如果有新的店賣炸雞腿，我們也不可能知道（不利於擴充套件）。

2.介面在日常生活中的對映

日常生活中，兩個實體之間進行連線的部分稱為介面。如電腦和U盤連線的標準USB介面。介面可以確保不同實體之間的順利連線。如不同的電腦廠家和U盤廠家只要按照相同的USB介面進行生產，那麼所有的電腦和U盤就可以順利的連線起來。