單一職責原則 Single Responsibility Principle,簡稱SRP,就一個類而言,應該僅有一個引起它變化的原因。 同價位的相機和手機哪個拍照好? 我覺得說同價位都太謙虛了,低端的千元卡片機完全可以弔打比自身貴至少三五倍價錢的手機,如果是萬元單反,我覺得市場上已經沒有什麼手機的拍 ...
單一職責原則
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; } }
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 HiddenWeapon("繡花針",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.8
凡是已經上線了的代碼,都是有意義的,經過重重測試才得以上線,如果在原來的代碼里修改東西,很容易影響到其他邏輯而不自知,你既在寫功能,又在寫Bug。
因此我們在設計程式的時候,應當儘量思考一下即將出現的變化,這樣在未來進行擴展的時候可以做到游刃有餘,在增加功能的時候,應當遵守開閉原則,擴展,而非修改。