本章我們要講解的是S.O.L.I.D五大原則JavaScript語言實現(xiàn)的第3篇,里氏替換原則LSP(The?Liskov Substitution Principle )。
英文原文:http://freshbrewedcode.com/derekgreer/2011/12/31/solid-javascript-the-liskov-substitution-principle/
開閉原則的描述是:
Subtypes must be substitutable for their base types.
派生類型必須可以替換它的基類型。
在面向?qū)ο缶幊汤铮^承提供了一個機制讓子類和共享基類的代碼,這是通過在基類型里封裝通用的數(shù)據(jù)和行為來實現(xiàn)的,然后已經(jīng)及類型來聲明更詳細的子類型,為了應(yīng)用里氏替換原則,繼承子類型需要在語義上等價于基類型里的期望行為。
為了來更好的理解,請參考如下代碼:
function Vehicle(my) {
var my = my || {};
my.speed = 0;
my.running = false;
this.speed = function() {
return my.speed;
};
this.start = function() {
my.running = true;
};
this.stop = function() {
my.running = false;
};
this.accelerate = function() {
my.speed++;
};
this.decelerate = function() {
my.speed--;
}, this.state = function() {
if (!my.running) {
return "parked";
}
else if (my.running && my.speed) {
return "moving";
}
else if (my.running) {
return "idle";
}
};
}
上述代碼我們定義了一個Vehicle函數(shù),其構(gòu)造函數(shù)為vehicle對象提供了一些基本的操作,我們來想想如果當前函數(shù)當前正運行在服務(wù)客戶的產(chǎn)品環(huán)境上,如果現(xiàn)在需要添加一個新的構(gòu)造函數(shù)來實現(xiàn)加快移動的vehicle。思考以后,我們寫出了如下代碼:
function FastVehicle(my) {
var my = my || {};
var that = new Vehicle(my);
that.accelerate = function() {
my.speed += 3;
};
return that;
}
在瀏覽器的控制臺我們都測試了,所有的功能都是我們的預(yù)期,沒有問題,F(xiàn)astVehicle的速度增快了3倍,而且繼承他的方法也是按照我們的預(yù)期工作。此后,我們開始部署這個新版本的類庫到產(chǎn)品環(huán)境上,可是我們卻接到了新的構(gòu)造函數(shù)導(dǎo)致現(xiàn)有的代碼不能支持執(zhí)行了,下面的代碼段揭示了這個問題:
var maneuver = function(vehicle) {
write(vehicle.state());
vehicle.start();
write(vehicle.state());
vehicle.accelerate();
write(vehicle.state());
write(vehicle.speed());
vehicle.decelerate();
write(vehicle.speed());
if (vehicle.state() != "idle") {
throw "The vehicle is still moving!";
}
vehicle.stop();
write(vehicle.state());
};
根據(jù)上面的代碼,我們看到拋出的異常是“The vehicle is still moving!”,這是因為寫這段代碼的作者一直認為加速(accelerate)和減速(decelerate)的數(shù)字是一樣的。但FastVehicle的代碼和Vehicle的代碼并不是完全能夠替換掉的。因此,F(xiàn)astVehicle違反了里氏替換原則。?
在這點上,你可能會想:“但,客戶端不能老假定vehicle都是按照這樣的規(guī)則來做”,里氏替換原則(LSP)的妨礙(譯者注:就是妨礙實現(xiàn)LSP的代碼)不是基于我們所想的繼承子類應(yīng)該在行為里確保更新代碼,而是這樣的更新是否能在當前的期望中得到實現(xiàn)。
上述代碼這個case,解決這個不兼容的問題需要在vehicle類庫或者客戶端調(diào)用代碼上進行一點重新設(shè)計,或者兩者都要改。
那么,我們?nèi)绾伪苊釲SP妨礙?不幸的話,并不是一直都是可以做到的。我們這里有幾個策略我們處理這個事情。
處理LSP過分妨礙的一個策略是使用契約,契約清單有2種形式:執(zhí)行說明書(executable specifications)和錯誤處理,在執(zhí)行說明書里,一個詳細類庫的契約也包括一組自動化測試,而錯誤處理是在代碼里直接處理的,例如在前置條件,后置條件,常量檢查等,可以從Bertrand Miller的大作《契約設(shè)計》中查看這個技術(shù)。雖然自動化測試和契約設(shè)計不在本篇文字的范圍內(nèi),但當我們用的時候我還是推薦如下內(nèi)容:
對于你自己要維護和實現(xiàn)的代碼,使用契約設(shè)計趨向于添加很多不必要的代碼,如果你要控制輸入,添加測試是非常有必要的,如果你是類庫作者,使用契約設(shè)計,你要注意不正確的使用方法以及讓你的用戶使之作為一個測試工具。
避免LSP妨礙的另外一個測試是:如果可能的話,盡量不用繼承,在Gamma的大作《Design Patterns – Elements of Reusable Object-Orineted Software》中,我們可以看到如下建議:
Favor object composition over class inheritance
盡量使用對象組合而不是類繼承
有些書里討論了組合比繼承好的唯一作用是靜態(tài)類型,基于類的語言(例如,在運行時可以改變行為),與JavaScript相關(guān)的一個問題是耦合,當使用繼承的時候,繼承子類型和他們的基類型耦合在一起了,就是說及類型的改變會影響到繼承子類型。組合傾向于對象更小化,更容易想靜態(tài)和動態(tài)語言語言維護。
到現(xiàn)在,我們討論了和繼承上下文在內(nèi)的里氏替換原則,指示出JavaScript的面向?qū)ο髮?。不過,里氏替換原則(LSP)的本質(zhì)不是真的和繼承有關(guān),而是行為兼容性。JavaScript是一個動態(tài)語言,一個對象的契約行為不是對象的類型決定的,而是對象期望的功能決定的。里氏替換原則的初始構(gòu)想是作為繼承的一個原則指南,等價于對象設(shè)計中的隱式接口。
舉例來說,讓我們來看一下Robert C. Martin的大作《敏捷軟件開發(fā) 原則、模式與實踐》中的一個矩形類型:
考慮我們有一個程序用到下面這樣的一個矩形對象:
var rectangle = {
length: 0,
width: 0
};
過后,程序有需要一個正方形,由于正方形就是一個長(length)和寬(width)都一樣的特殊矩形,所以我們覺得創(chuàng)建一個正方形代替矩形。我們添加了length和width屬性來匹配矩形的聲明,但我們覺得使用屬性的getters/setters一般我們可以讓length和width保存同步,確保聲明的是一個正方形:
var square = {};
(function() {
var length = 0, width = 0;
// 注意defineProperty方式是262-5版的新特性
Object.defineProperty(square, "length", {
get: function() { return length; },
set: function(value) { length = width = value; }
});
Object.defineProperty(square, "width", {
get: function() { return width; },
set: function(value) { length = width = value; }
});
})();
不幸的是,當我們使用正方形代替矩形執(zhí)行代碼的時候發(fā)現(xiàn)了問題,其中一個計算矩形面積的方法如下:
var g = function(rectangle) {
rectangle.length = 3;
rectangle.width = 4;
write(rectangle.length);
write(rectangle.width);
write(rectangle.length * rectangle.width);
};
該方法在調(diào)用的時候,結(jié)果是16,而不是期望的12,我們的正方形square對象違反了LSP原則,square的長度和寬度屬性暗示著并不是和矩形100%兼容,但我們并不總是這樣明確的暗示。解決這個問題,我們可以重新設(shè)計一個shape對象來實現(xiàn)程序,依據(jù)多邊形的概念,我們聲明rectangle和square,relevant。不管怎么說,我們的目的是要說里氏替換原則并不只是繼承,而是任何方法(其中的行為可以另外的行為)。
里氏替換原則(LSP)表達的意思不是繼承的關(guān)系,而是任何方法(只要該方法的行為能體會另外的行為就行)。
更多建議: