關於面對對對象之接口的通俗理解

一些人寫代碼，按照計算機思考的那個模式寫，寫出來的代碼，能實現功能，可是拓展性很差，而有些人寫代碼，是按照人看世界的那些思路去寫，寫出來的代碼 看起來像那麼回事兒，並且也很是的符合邏輯，這是爲何？爲何一樣是寫代碼，爲何寫出來的東西會徹底不同了？

最近一直在反思本身寫的代碼，之前寫，都是爲了完成某項功能而寫，寫完了也就完事兒了，但是最近卻不是這樣了，最近想打問題是，寫代碼是否是隻要在實現功能的層面上就能夠了了？後來得出的答案是，代碼其實還能夠寫的更加的靈活多變一點的

那麼今天咱們就來談談關於這個寫代碼的技巧性的東西，咱們常常在一些場合裏面去使用面對對象的思想去編程，但是，在我真正的工做經驗中所看到的卻每每不是這樣，他們不少的時候是打着面對對象的幌子卻從事着面對過程編程的勾當。

咱們來假設一下咱們如今的一些個情景，不少人常常編寫那種基於用戶角色的管理系統，好比會員管理系統中的積分計算方式，好比A級別的會員，購買了B商品，他此時能夠獲得積分爲C的相應積分，而B級別的會員，購買了B商品，他此時的到的積分爲C+3的積分，那麼我是試想一下，我麼應該如何編寫這種積分編寫的規則了？

試想 咱們若是使用咱們最多見的那種方式，咱們80%的狀況下咱們可能會這樣寫？

//僞代碼
if(level==A){
    count(C);//計算A級別會員積分
}
if(level==B){
    count(+3)://計算B級別會員積分
}

按照以上的這種方式，隨着等級增長，這樣的判斷類型會愈來愈多，這樣的直接結果就是致使咱們須要維護的文件會愈來愈多，代碼也會愈來愈臃腫。最後代碼就直接腐爛變質了

那麼，另外的一種寫法是怎麼樣了？

//僞代碼
public interface IMember(){

    public double count(double value);
}

public class Amember implements IMember(){
    public double count(double value){
    
        value = value+C;
        return value;
    }
    
public class BMember impelents IMember(){
 
 public double count(double value){
    
        value = value+C+3;
        return value;
    }   
}

而後 咱們只要根據登陸的不一樣會員信息去產生不一樣的對象實例，調用一樣的一個計算方式就行了。那麼 這樣 咱們只須要在增長類的時候去添加對應的等級Member對象就能夠了，這樣咱們就成功的將代碼分開放置在了不一樣的類文件中，這樣的話可以以最小的更改代價而完成最新的需求變動。

其實我想要表達的意思就是，若是想要用好面對對象的這個思惟去編寫程序，那麼其實咱們是有標準能夠參照的。今天先只說一部分，之後再慢慢更。

首先要明白接口的使用，這個是面對對象當中最最最最重要的東西，沒有之一。關於接口的書面描述，我就不想再多說了，各類參考書中都放置了至關多的描述，如今我主要是想說我對這個接口的理解和一些常見的疑惑問題解答。

一、在設計編碼的書中中經常提及，要記住面對對抽象編程，而不是面對對具體實現編程？爲何

其實答案很簡單，可是要想明白可能不是那麼容易，我試着用最簡單的方式去告訴大家怎麼回事，接口當中，咱們經常會寫一些方法對吧。並且這些方法每每是沒有任何實現的對吧？那麼，那些數據中所說的面對抽象編程，其實就是指這個沒有實現的方法編程。爲何？由於接口中定義的方法，他必定是抽象的 儘管你沒有顯示的說明他是抽象的，但是事實倒是如此的。

並且，這些抽象的方法映射到咱們的實際開發當中來講，這些個方式是一羣對象所同時具備的一些個動做，只是具體的實現不一樣而已，這樣一說，你是否是就可以很好的明白了這個接口到底什麼什麼玩意，能夠用來作什麼？ 面對對象的面對抽象編程就是這麼個道理和內涵。

其實你能夠發現好多設計精良的架構設計，你會發現裏面有一堆的接口，而後有不少的類結構會去實現這樣的接口，從而使得本身可以擁有一些個可以供本身使用的方法，因此在此我推薦的是，全部類中除了類自己全部用的一些相似於輔助的方法以外，其餘的方法最好所有放到各個接口當中去實現最好，由於這樣維護的成爲最低，修改的代碼成本最小。

其實不少人在編寫代碼以前的時候會時刻提醒本身 咱們不能按照面對過程的方式來編寫代碼，可是一旦項目開動了，這些基本都不靠譜了。爲何了，由於他腦子裏的潛意識永遠沒有去想，我這個方法究竟是從哪兒來的？因此我給你們提的建議是思考以下三個問題，在你編寫一個類的時候！

一、個人類是JAVABean麼？這個裏面除了getter,setter方法以外，其餘的不要放

二、個人類中的方法是從某個接口中實現而來的麼？不過建議先思考這樣的問題在決定你的方法的來源，這樣會更加省事兒的，血的教訓

三、停頓60秒，而後再問本身以上的這兩個問題

說一千到一萬，其實接口就解決了一個問題，那就是不少動做的共性問題，簡單點就是說，A有呼喊的技能，B也有呼喊的技能，不過A只會呼喊A語言，B會呼喊B語言的，那麼假如咱們使用了接口，則自動的屏蔽了具體的實現。這樣就到達了多態（也就是對象實例爲A時，A開始呼喊，對象實例爲B時，B仍是呼喊）。

在直白一點咱們能夠這樣理解，接口其實就是一個領導，他只能在哪兒交換，歷來不會去管下面如何實現的，他只要結果，因此，實現接口的類就像是領導直接管轄的下屬，你只要按照他的大方向去作，而後告訴領導結果就夠了。具體你怎麼去作，就i本身想去吧...領導歷來不會問你技術細節，由於他有本身有本身的宏（SHA）偉(BI)藍(YI)圖(GE)

囉嗦幾句，編程須要技巧和思惟，不過在這裏在澄清一個誤區，那就是業界流傳着一句話說「多寫多練」你就能成爲大牛？我謝謝你，代碼多寫多看，而不去多想，你永遠就是一個熟練工，一個CODER，而不是DEVELOPER好麼。因此奉勸各位看到此文章的博友們，謹記着一句話，「多寫多練變大牛」是有前提條件的好麼，必定是要在「多想多總結」的基礎上完成！！任何的語句有意義都是會有上下文語境的，這就是設計的哲學。