概述 簡單介紹一下七大設計原則: 1. 開閉原則 :是所有面向對象設計的核心,對擴展開放,對修改關閉 2. 依賴倒置原則 :針對介面編程,依賴於抽象而不依賴於具體 3. 單一職責原則 :一個介面只負責一件事情,只能有一個原因導致類變化 4. 介面隔離原則 :使用多個專門的介面,而不是使用一個總介面 ...
概述
簡單介紹一下七大設計原則:
- 開閉原則:是所有面向對象設計的核心,對擴展開放,對修改關閉
- 依賴倒置原則:針對介面編程,依賴於抽象而不依賴於具體
- 單一職責原則:一個介面只負責一件事情,只能有一個原因導致類變化
- 介面隔離原則:使用多個專門的介面,而不是使用一個總介面
- 迪米特法則(最少知道原則):只和朋友交流(成員變數、方法輸入輸出參數),不和陌生人說話,控制好訪問修飾符
- 里氏替換原則:子類可以擴展父類的功能,但不能改變父類原有的功能
- 合成復用原則:儘量使用對象組合(has-a)/聚合(contanis-a),而不是繼承關係達到軟體復用的目的
迪米特法則
定義
迪米特原則(Law of Demeter LoD)是指一個對象應該對其他對象保持最少的瞭解,又 叫最少知道原則(Least Knowledge Principle,LKP),儘量降低類與類之間的耦合。
迪米特原則主要強調只和朋友交流,不和陌生人說話。出現在成員變數、方法的輸入、輸 出參數中的類都可以稱之為成員朋友類,而出現在方法體內部的類不屬於朋友類。
示例
現在來設計一個許可權系統,Boss 需要查看目前發佈到線上的課程數量。這時候,Boss 要找到 TeamLeader 去進行統計,TeamLeader 再把統計結果告訴 Boss。接下來我們還 是來看代碼:
Course
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:17
*/
public class Course {
}
TeamLeader
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:17
*/
public class TeamLeader {
public void checkNumberOfCourses(List<Course> courseList) {
System.out.println("目前已發佈的課程數量是:" + courseList.size());
}
}
Boss
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:17
*/
public class Boss {
public void commandCheckNumber(TeamLeader teamLeader) {
//模擬 Boss 一頁一頁往下翻頁,TeamLeader 實時統計
List<Course> courseList = new ArrayList<Course>();
for (int i = 0; i < 20; i++) {
courseList.add(new Course());
}
teamLeader.checkNumberOfCourses(courseList);
}
}
測試代碼:
public static void main(String[] args) {
Boss boss = new Boss();
TeamLeader teamLeader = new TeamLeader();
boss.commandCheckNumber(teamLeader);
}
寫到這裡,其實功能已經都已經實現,代碼看上去也沒什麼問題。根據迪米特原則,Boss
只想要結果,不需要跟 Course
產生直接的交流。而 TeamLeader
統計需要引用 Course
對象。Boss
和 Course
並不是朋友,從下麵的類圖就可以看出來:
下麵來對代碼進行改造:
TeamLeader
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:17
*/
public class TeamLeader {
public void checkNumberOfCourses() {
List<Course> courseList = new ArrayList<Course>();
for (int i = 0; i < 20; i++) {
courseList.add(new Course());
}
System.out.println("目前已發佈的課程數量是:" + courseList.size());
}
}
Boss
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:17
*/
public class Boss {
public void commandCheckNumber(TeamLeader teamLeader) {
teamLeader.checkNumberOfCourses();
}
}
再來看下麵的類圖,Course 和 Boss 已經沒有關聯了。
學習軟體設計原則,千萬不能形成強迫症。碰到業務複雜的場景,我們需要隨機應變。
里氏替換原則
定義
里氏替換原則(Liskov Substitution Principle,LSP)是指如果對每一個類型為 T1 的對 象 o1,都有類型為 T2 的對象 o2,使得以 T1 定義的所有程式 P 在所有的對象 o1 都替換成 o2 時,程式 P 的行為沒有發生變化,那麼類型 T2 是類型 T1 的子類型。
定義看上去還是比較抽象,我們重新理解一下,可以理解為一個軟體實體如果適用一個 父類的話,那一定是適用於其子類,所有引用父類的地方必須能透明地使用其子類的對象,子類對象能夠替換父類對象,而程式邏輯不變。根據這個理解,我們總結一下:
引申含義:子類可以擴展父類的功能,但不能改變父類原有的功能。
- 子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類的方法重載父類的方法時,方法的前置條件(即方法的輸入/入參)要比父類 方法的輸入參數更寬鬆。
- 當子類的方法實現父類的方法時(重寫/重載或實現抽象方法),方法的後置條件(即 方法的輸出/返回值)要比父類更嚴格或相等。
示例
在前面講開閉原則的時候埋下了一個伏筆,我們記得在獲取折後時重寫覆蓋了父類的 getPrice()
方法,增加了一個獲取原價格的方法 getOriginPrice()
,顯然就違背了里氏替換 原則。我們修改一下代碼,不應該覆蓋 getPrice()
方法,增加 getDiscountPrice()
方法:
/**
* @author eamon.zhang
* @date 2019-09-25 上午10:36
*/
public class NovelDiscountBook extends NovelBook {
public NovelDiscountBook(String name, int price, String author) {
super(name, price, author);
}
public double getDiscountPrice(){
return super.getPrice() * 0.85;
}
}
使用里氏替換原則有以下優點:
- 約束繼承泛濫,開閉原則的一種體現。
- 加強程式的健壯性,同時變更時也可以做到非常好的相容性,提高程式的維護性、擴 展性。降低需求變更時引入的風險。
現在來描述一個經典的業務場景,用正方形、矩形和四邊形的關係說明裡氏替換原則, 我們都知道正方形是一個特殊的長方形,那麼就可以創建一個長方形父類 Rectangle
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:59
*/
public class Rectangle {
private long height;
private long width;
public long getHeight() {
return height;
}
public void setHeight(long height) {
this.height = height;
}
public long getWidth() {
return width;
}
public void setWidth(long width) {
this.width = width;
}
}
創建正方形 Square
類繼承長方形:
/**
* @author eamon.zhang
* @date 2019-09-26 上午10:01
*/
public class Square extends Rectangle {
private long length;
public long getLength() {
return length;
}
public void setLength(long length) {
this.length = length;
}
@Override
public long getHeight() {
return super.getHeight();
}
@Override
public void setHeight(long height) {
super.setHeight(height);
}
@Override
public long getWidth() {
return super.getWidth();
}
@Override
public void setWidth(long width) {
super.setWidth(width);
}
}
在測試類中創建 resize()
方法,根據邏輯長方形的寬應該大於等於高,我們讓高一直自增, 知道高等於寬變成正方形:
public static void resize(Rectangle rectangle) {
while (rectangle.getWidth() >= rectangle.getHeight()) {
rectangle.setHeight(rectangle.getHeight() + 1);
System.out.println("width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
}
System.out.println("resize 方法結束" +
"\nwidth:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
}
測試代碼:
public static void main(String[] args) {
Rectangle rectangle = new Rectangle();
rectangle.setWidth(20);
rectangle.setHeight(10);
resize(rectangle);
}
運行結果:
發現高比寬還大了,在長方形中是一種非常正常的情況。現在我們再來看下麵的代碼, 把長方形 Rectangle
替換成它的子類正方形 Square
,修改測試代碼:
public static void main(String[] args) {
Square square = new Square();
square.setLength(10);
resize(square);
}
這時候我們運行的時候就出現了死迴圈,違背了里氏替換原則,將父類替換為子類後, 程式運行結果沒有達到預期。因此,我們的代碼設計是存在一定風險的。里氏替換原則 只存在父類與子類之間,約束繼承泛濫。我們再來創建一個基於長方形與正方形共同的 抽象四邊形 Quadrangle
介面:
/**
* @author eamon.zhang
* @date 2019-09-26 上午10:12
*/
public interface Quadrangle {
long getWidth();
long getHeight();
}
修改長方形 Rectangle
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午9:59
*/
public class Rectangle implements Quadrangle {
private long height;
private long width;
@Override
public long getWidth() {
return width;
}
public long getHeight() {
return height;
}
public void setHeight(long height) {
this.height = height;
}
public void setWidth(long width) {
this.width = width;
}
}
修改正方形類 Square
類:
/**
* @author eamon.zhang
* @date 2019-09-26 上午10:01
*/
public class Square implements Quadrangle {
private long length;
public long getLength() {
return length;
}
public void setLength(long length) {
this.length = length;
}
@Override
public long getWidth() {
return length;
}
@Override
public long getHeight() {
return length;
}
}
此時,如果我們把 resize()
方法的參數換成四邊形 Quadrangle
類,方法內部就會報錯。
因為正方形 Square
已經沒有了 setWidth()
和 setHeight()
方法了。因此,為了約束繼承 泛濫,resize()
的方法參數只能用 Rectangle
長方形。當然,我們在後面的設計模式系列文章中 中還會繼續深入講解。