Javascript中的幾種繼承方式比較

衣舞晨風發表於2015-12-30

原文地址

開篇

從’嚴格’意義上說,javascript並不是一門真正的面嚮物件語言。這種說法原因一般都是覺得javascript作為一門弱型別語言與類似java或c#之類的強型語言的繼承方式有很大的區別,因而預設它就是非主流的物件導向方式,甚至竟有很多書將其描述為’非完全物件導向’語言。其實個人覺得,什麼方式並不重要,重要的是是否具有物件導向的思想,說javascript不是面嚮物件語言的,往往都可能沒有深入研究過javascript的繼承方式,故特撰此文以供交流。

為何需要利用javascript實現繼承?

早期pc機器的效能確實不敢恭維,所有的壓力全在伺服器端,客戶端瀏覽器純屬擺設。再加上那時流行的table佈局以及電話線的上網方式導致瀏覽一個網頁十分的卡;而今網際網路時代飛速發展,個人電腦硬體得到了極大提升,客戶端瀏覽器的效能也十分的酸爽,web開發的模式也在悄悄改變:服務端不再像以前那樣“辛苦”,取而代之的是儘可能的讓瀏覽器承擔更多的任務,如此一來,壓力分攤到每個客戶端上,企業不但節省成本,隨之也讓web前端開發變的更加有趣--越來越多的前端框架層出不窮,甚至出現了許多前端的MVC框架。在這種背景下,javascript的角色已經絕對不是隻做一些簡單的驗證,傳送一些請求或者操作一些DOM,更多的需要擔任類似前端路由和業務層的角色,並且javascript需要做大量的邏輯性任務,這裡面就包括前臺資料的抽離(即model),而只有運用物件導向的思維才能很好的對抽離資料進行處理,因此繼承就在這裡顯得舉足輕重。

從一個簡單的需求開始

現從前臺抽離一個model名為Person,其有基本屬性name和age,預設每個人都會說話,因此將說話的功能say放在了原型物件上,以供每個例項享用。現在對於Man來說,它需要繼承Person的基本屬性,並且在此基礎上新增自己特有的屬性。

 function Person(name, age) {
            this.name = name;
            this.age = age;
        }
        Person.prototype.say = function () {
            alert('hello, my name is ' + this.name);
        };
        function Man() {
        }
        Man.prototype = new Person('pursue');
        var man1 = new Man();
        man1.say(); //hello, my name is pursue
        var man2 = new Man();
        alert(man1.say === man2.say);//true
        alert(man1.name === man2.name);//true

下面介紹幾種主流的繼承方式。

1.原型鏈繼承

  function Person(name, age) {
            this.name = name;
            this.age = age;
        }
        Person.prototype.say = function () {
            alert('hello, my name is ' + this.name);
        };
        function Man() {
        }
        Man.prototype = new Person('pursue');
        var man1 = new Man();
        man1.say(); //hello, my name is pursue
        var man2 = new Man();
        alert(man1.say === man2.say);//true
        alert(man1.name === man2.name);//true

這種繼承方式很直接,為了獲取Person的所有屬性方法(例項上的和原型上的),直接將父類的例項new Person(‘pursue’)賦給了子類的原型,其實子類的例項man1,man2本身是一個完全空的物件,所有的屬性和方法都得去原型鏈上去找,因而找到的屬性方法都是同一個。
所以直接利用原型鏈繼承是不現實的。

2.利用建構函式繼承

function Person (name, age) {
    this.name = name;
    this.age = age;
}
Person.prototype.say = function(){
    alert('hello, my name is ' + this.name);
};
function Man(name, age) {
    Person.apply(this, arguments);
}
//Man.prototype = new Person('pursue');
var man1 = new Man('joe');
var man2 = new Man('david');
alert(man1.name === man2.name);//false
man1.say(); //say is not a function

這裡子類的在建構函式裡利用了apply去呼叫父類的建構函式,從而達到繼承父類屬性的效果,比直接利用原型鏈要好的多,至少每個例項都有自己那一份資源,但是這種辦法只能繼承父類的例項屬性,因而找不到say方法,為了繼承父類所有的屬性和方法,則就要修改原型鏈,從而引入了組合繼承方式。

3.組合繼承

function Person(name, age) {
            this.name = name;
            this.age = age;
        }
        Person.prototype.say = function () {
            alert('hello, my name is ' + this.name);
        };
        function Man(name, age) {
            Person.apply(this, arguments);
        }
        Man.prototype = new Person();
        var man1 = new Man('joe');
        var man2 = new Man('david');
        alert(man1.name === man2.name);//false
        alert(man1.say === man2.say);//true
        man1.say(); //hello, my name is joe

需要注意的是man1和man2的例項屬性其實是覆蓋了原型屬性,但是並沒要覆蓋掉原型上的say方法(因為它們沒有),所以這裡man1.say === man2.say依然返回true,因而需要十分小心沒有覆蓋掉的原型屬性,因為它是所有例項共有的。

4.寄生組合繼承

說實話我真不知道下面的這種形式叫這名字,但是它確實是最流行,最經典的javascript的繼承方式。其實,只需要明白原型物件的結構即可:

function Person (name, age) {
            this.name = name;
            this.age = age;
        }
Person.prototype.say = function(){
    alert('hello, my name is ' + this.name);
};
function Man(name, age) {
    Person.apply(this, arguments);
}
Man.prototype = Object.create(Person.prototype);//a.
Man.prototype.constructor = Man;//b.
var man1 = new Man('pursue');
var man2 = new Man('joe');
alert(man1.say == man2.say);
alert(man1.name == man2.name);

其實寄生組合繼承和上面的組合繼承區別僅在於構造子類原型物件的方式上(a.和b.),這裡用到了Object.creat(obj)方法,該方法會對傳入的obj物件進行淺拷貝,類似於:

function create(obj){
    function T(){};
    T.prototype = obj;
    return new T();
}

因此,a.會將子類的原型物件與父類的原型物件進行很好的連線,而並不像一般的組合繼承那樣直接對子類的原型進行復制(如Man.prototype = new Person();),這樣只是很暴力的在對屬性進行覆蓋。而寄生組合繼承方式則對例項屬性和原型屬性分別進行了繼承,在實現上更加合理。

注意:程式碼b.並不會改變instanceof的結果,但是對於需要用到construcor的場景,這麼做更加嚴謹。

相關文章