六大設計原則

不該相遇在秋天發表於2019-03-05

單一職責原則

　　Single Responsibility Principle，簡稱SRP，就一個類而言，應該僅有一個引起它變化的原因。

同價位的相機和手機哪個拍照好？

　　我覺得說同價位都太謙虛了，低端的千元卡片機完全可以吊打比自身貴至少三五倍價錢的手機，如果是萬元單反，我覺得市場上已經沒有什麼手機的拍照效果可以與之相抗了。

　　整合當然是一種很好的思想，是時代發展的主方向，但是我們在進行程式設計的時候，更應該要在類的職責分離上多思考，做到單一職責，這樣的程式碼才容易維護與複用。

單一職責的好處

1.類的複雜性降低。
2.可讀性提高。
3.可維護性提高。
4.變更引起的風險降低。

很難實踐

　　然而，這個設計原則飽受爭議，很難在專案中得到體現。

　　原因在於，職責邊界很難劃分，每個人的看法不同，並且隨著專案功能的不斷迭代，開發人員必須要做出相應的妥協，想要保持類的單一職責幾乎不可能，否則就會冗餘出非常多的類檔案。

　　而我們設計類的時候應該做的是：介面一定要遵守單一職責原則，實現類儘量遵守單一職責原則。

里氏替換原則

　　Liskov Substitution Principle，里氏替換原則，簡稱LSP，任何基類可以出現的地方，子類一定可以出現。

　　LSP原則是繼承複用的基石。

武器設計

　　我們都看過電影裡動作演員打架，他們的武器有各種各樣的刀、劍、暗器等等。。。

　　根據里氏替換原則，類圖就可以這樣設計：

程式示例

武器的抽象類

public abstract class AbstractWeapon {
    //攻擊
    public abstract void attack();
}

刀

public class Knife extends AbstractWeapon {
    @Override
    public void attack() {
        System.out.println("用刀發起普通攻擊");
    }
}

劍

public class Sword extends AbstractWeapon {
    @Override
    public void attack() {
        System.out.println("用劍發起普通攻擊");
    }
}

人物類

public class Person {
    private AbstractWeapon weapon;//武器

    public Person(AbstractWeapon weapon) {
        this.weapon = weapon;//初始化給一把武器
    }

    //發起攻擊
    public void attack(){
        weapon.attack();
    }

}

呼叫

    public static void main(String[] args) {
        Person a = new Person(new Knife());
        a.attack();

        Person b = new Person(new Sword());
        b.attack();
    }

輸出：

刀發起普通攻擊
劍發起普通攻擊

　　示例中程式碼的核心在於使用父類做為引數，那麼子類不管什麼武器都可以傳入，里氏替換原則的目的就是增強程式的健壯性，對業務的橫向擴充套件有著很好的支援。

依賴倒置原則

　　Dependence Inversion Principle，依賴倒置原則，簡稱DIP，

　　a.高層次的模組不應該依賴低層次的模組，他們都應該依賴於抽象。

　　b.抽象不應該依賴於具體，具體應該依賴於抽象。

　　這話說簡單點就是要針對介面程式設計，不要針對實現程式設計。

　　比方說電腦的滑鼠、鍵盤都是針對介面設計的，如果針對實現來設計的話，那麼滑鼠就要對應到具體的哪個品牌的主機板，買個滑鼠得去研究是否適用於當前電腦主機板的型號。

優化武器程式

　　既然要針對介面程式設計，那麼我們就稍微改一下上面的程式，給Person加個抽象（我這裡使用的是抽象類，也可以使用介面，都符合原則）

人物抽象

public abstract class AbstractPerson {
    protected String name;//每個人都有名字
    protected AbstractWeapon weapon;//武器

    //建立人物
    public AbstractPerson(String name,AbstractWeapon weapon) {
        this.name = name;
        this.weapon = weapon;
    }

    public abstract void attack();//攻擊
}

人物

public class Person extends AbstractPerson{

    public Person(String name, AbstractWeapon weapon) {
        super(name, weapon);
    }

    //發起攻擊
    public void attack(){
        System.out.print(this.name + "上場,");
        this.weapon.attack();
    }
}

呼叫

    public static void main(String[] args) {
        AbstractPerson a = new Person("張三",new Knife());
        a.attack();

        AbstractPerson b = new Person("李四",new Sword());
        b.attack();
    }

輸出：

張三上場,用刀發起普通攻擊
李四上場,用劍發起普通攻擊

細細看來，在main方法裡依賴的就是AbstractPerson這個抽象了，在Person類裡依賴的也是AbstractWeapon抽象，完全符合依賴導致原則。

1.每個類儘量都有介面或抽象類。

2.變數的表面型別儘量是介面或抽象類。

介面隔離原則

　　Interface Segregation Principle，介面隔離原則，簡稱ISP，客戶端不應該依賴它不需要的介面，一個類對另一個類的依賴應該建立在最小的介面上。

　　簡單點說，就是要細化介面，介面的方法儘量少。如果一個介面為多個模組提供訪問，那麼這個介面就應該進行拆分。

　　介面隔離原則實際上也很難得到體現，介面的粒度越小，就越是隔離，系統越靈活，但是，系統結構越是複雜，開發難度增加，可維護性降低，所以，遵守介面隔離原則需要一個度。

迪米特法則

　　Law of Demeter，迪米特法則，又叫做最少知識原則（Least Knowledge Principle），就是說一個物件應當對其他物件有儘可能少的瞭解,不和陌生人說話。

　　迪米特法則的初衷在於降低類之間的耦合。由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係。

迪米特法則的核心觀念就是類與類間要解耦，
1.優先考慮將一個類設定成不變類
2.儘量降低一個類的訪問許可權。
3.謹慎使用Serializable（防止改變引起反序列化失敗）。
4.儘量降低成員的訪問許可權。

開閉原則

　　先來看看開閉原則的定義：一個軟體實體（類、模組、函式等等）應該對擴充套件開放，對修改關閉。

　　這意味著一個實體是允許在不改變它的原始碼的前提下變更它的行為，做到真正的擁抱變化。

武器展覽

那我們就舉例說明一下什麼是開閉原則，就以武器作為原型故事吧

武器通用介面

public interface IWeapon {
    String getName();//每個武器都有名稱
    Integer getAtk();//每個武器都有攻擊力
    Float getCrit();//暴擊率
}

武器類

public class Weapon implements IWeapon {
    private String name;//武器名稱
    private Integer atk;//攻擊力
    private Float crit;//暴擊率

    public Weapon(String name, Integer atk, Float crit) {
        this.name = name;
        this.atk = atk;
        this.crit = crit;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public Integer getAtk() {
        return atk;
    }

    @Override
    public Float getCrit() {
        return crit;
    }
}

main方法

    public static void main(String[] args) {
        ArrayList<IWeapon> weapons = new ArrayList<>();
        weapons.add(new Weapon("倚天劍",1200,0.6F));
        weapons.add(new Weapon("打狗棒",850,0.7F));
        weapons.add(new Weapon("血飲狂刀",900,0.56F));
        weapons.add(new Weapon("繡花針",900,0.7F));

        for(IWeapon weapon : weapons){
            System.out.println(weapon.getName() + ",攻擊力是" + weapon.getAtk() + ",暴擊"+weapon.getCrit());
        }
    }

輸出：

倚天劍,攻擊力是1200,暴擊0.6
打狗棒,攻擊力是850,暴擊0.7
血飲狂刀,攻擊力是900,暴擊0.56
繡花針,攻擊力是900,暴擊0.7

東方不敗的繡花針

　　現在，我們來加一個需求，東方不敗的武器繡花針，實際暴擊應該在原基礎上增加0.1，因為飛刀暗器之類的兵器總是讓人防不勝防。

面對這個需求，我們來研究一下解決辦法

既然繡花針是特殊的武器，那麼我們就在Weapon類增加一個引數，是否加暴，如果為true，那麼就增加0.1的暴擊，怎麼傳入呢？那就過載一個建構函式即可。

修改後的Weapon類

public class Weapon implements IWeapon {
    private String name;//武器名稱
    private Integer atk;//攻擊力
    private Float crit;//暴擊率
    private boolean isAddCrit = false;

    public Weapon(String name, Integer atk, Float crit) {
        this.name = name;
        this.atk = atk;
        this.crit = crit;
    }

    public Weapon(String name, Integer atk, Float crit,boolean isAddCrit) {
        this.name = name;
        this.atk = atk;
        this.crit = crit;
        this.isAddCrit = isAddCrit;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public Integer getAtk() {
        return atk;
    }

    @Override
    public Float getCrit() {
        return isAddCrit ? crit + 0.1F : crit;
    }
}

修改後的main方法

    public static void main(String[] args) {
        ArrayList<IWeapon> weapons = new ArrayList<>();
        weapons.add(new Weapon("倚天劍",1200,0.6F));
        weapons.add(new Weapon("打狗棒",850,0.7F));
        weapons.add(new Weapon("血飲狂刀",900,0.56F));
        weapons.add(new Weapon("繡花針",900,0.7F,true));

        for(IWeapon weapon : weapons){
            System.out.println(weapon.getName() + ",攻擊力是" + weapon.getAtk() + ",暴擊"+weapon.getCrit());
        }
    }

輸出：

倚天劍,攻擊力是1200,暴擊0.6
打狗棒,攻擊力是850,暴擊0.7
血飲狂刀,攻擊力是900,暴擊0.56
繡花針,攻擊力是900,暴擊0.8

看吧，繡花針的暴擊已經達到了0.8，不再是0.7了。

實踐

　　這個解決辦法有沒有問題呢？當然有的。

　　沒有的話那我不成傻逼了嗎？

　　有的人可能會把介面增加一個addCrit方法，但你不管怎麼折騰，你都是要在原來的結構裡進行修改，實現類無論如何都要改，才能完成新需求。

　　但是這裡呢，我們使用繼承來做反而更簡單，又不破壞原來的程式結構。

新的類圖

看到了嗎？我們用一個新類，暗器類，繼承武器類，重寫getCrit()即可，既擁抱了變化，又沒有修改原來的邏輯。

暗器類

public class HiddenWeapon extends Weapon {
    public HiddenWeapon(String name, Integer atk, Float crit) {
        super(name, atk, crit);
    }

    @Override
    public Float getCrit() {
        return super.getCrit() + 0.1F;
    }
}