淺談JavaScript中的介面程式碼詳解-js教程-PHP中文網

一、什麼是介面

二、介面的利與弊

三、在JavaScript中模仿介面

四、Interface类

五、依赖于接口的设计模式

首頁

web前端

js教程

淺談JavaScript中的介面程式碼詳解

黄舟

Mar 04, 2017 pm 03:16 PM

javascript

一、什麼是介面

介面是物件導向JavaScript程式設計師的工具箱中最有用的工具之一。在設計模式中提出的可重用的物件導向設計的原則之一就是“針對介面編程而不是實現程式設計”，即我們所說的面向介面編程，這個概念的重要性可見一斑。但問題在於，在JavaScript的世界中，沒有內建的建立或實作介面的方法，也沒有可以判斷一個物件是否實作了與另一個物件相同的一套方法，這使得物件之間很難互換使用，好在JavaScript擁有出色的靈活性，這使得模擬傳統面向對象的接口，添加這些特性並非難事。介面提供了一種用以說明一個物件應該具有哪些方法的手段，儘管它可以顯示這些方法的意義，但是卻不包含具體實作。有了這個工具，就能依照物件提供的特性將它們分組。例如，假如A和B以及接口I，即便A對象和B對像有極大的差異，只要他們都實現了I接口，那麼在A.I(B)方法中就可以互換使用A和B，如B.I( A)。也可以使用介面開發不同的類別的共同性。如果把原本要求以一個特定的類別為參數的函數改為要求以一個特定的介面為參數的函數，那麼所有實作了該介面的物件都可以作為參數傳遞給它，這樣一來，彼此不相關的物件也可以被相同地對待。

二、介面的利與弊

既定的介面具有自我描述性，並能夠促進程式碼的重用性，介面可以提供一種訊息，告訴外部一個類別需要實現哪些方法。也有助於穩定不同類別之間的通訊方式，減少了繼承兩個物件的過程中出現的問題。這對於調試也是有幫助的，在JavaScript這種弱類型語言中，類型不匹配很難追踪，使用接口時，如果出現了問題，會有更明確的錯誤提示訊息。當然介面並非完全沒有缺點，如果大量使用介面會一定程度上弱化其作為弱類型語言的靈活性，另一方面，JavaScript並沒有對介面的內建的支持，只是對傳統的物件導向的介面進行模擬，這會讓本身較為靈活的JavaScript變得更難駕馭。此外，任何實作介面的方式都會對效能造成影響，某種程度上歸咎於額外的方法呼叫開銷。介面使用的最大的問題在於，JavaScript不像是其他的強類型語言，如果不遵守介面的約定，就會編譯失敗，其彈性可以有效地避開上述問題，如果是在協同開發的環境下，其介面很有可能被破壞而不會產生任何錯誤，也就是不可控性。

在物件導向的語言中，使用介面的方式大致相似。介面中包含的資訊說明了類別需要實作的方法以及這些方法的簽章。類別的定義必須明確地聲明它們實作了這些接口，否則是不會編譯通過的。顯然在JavaScript中我們不能如法炮製，因為不存在interface和implement關鍵字，也不會在運行時對接口是否遵循約定進行檢查，但是我們可以通過輔助方法和顯式地檢查模仿出其大部分特性。

三、在JavaScript中模仿介面

在JavaScript中模仿介面主要有三種方式：透過註解、屬性檢查和鴨式辯型法，以上三種方式有效結合，就會產生類似介面的效果。

註解是一種比較直觀地把與接口相關的關鍵字（如interface、implement等）與JavaScript程式碼一同放在註解中來模擬接口，這是最簡單的方法，但是效果最差。程式碼如下：

//以注释的形式模仿描述接口
/*
interface Composite{
    function add(child);
    function remove(child);
    function getName(index);
}

interface FormItem{
    function save();
}
*/

//以注释的形式模仿使用接口关键字
var CompositeForm =function(id , method,action) { //implements Composite , FormItem
    // do something
}
//模拟实现具体的接口方法 此处实现Composite接口
CompositeForm.prototype.Add=function(){
    // do something
}

CompositeForm.prototype.remove=function(){
    // do something
}

CompositeForm.prototype.getName=function(){
    // do something
}

//模拟实现具体的接口方法 此处实现FormItem接口
Composite.prototype.save=function(){
    // do something
}

登入後複製

這種方式其實並不是很好，因為這種模仿還只停留在文件規範的範疇，開發人員是否會嚴格遵守該約定有待考量，對介面的遵守完全依靠開發人員的自覺性。另外，這種方式並不會去檢查某個函數是否真正實現了我們約定的「介面」。儘管如此，這種方式也有優點，它易於實作而不需要額外的類別或函數，可以提高程式碼的可重用性，因為類別實作的介面都有註解說明。這種方式不會影響到檔案所佔用的空間或執行速度，因為註解的程式碼可以在部署的時候輕鬆剔除。但是由於不會提供錯誤訊息，它對測試和調試沒什麼幫助。下面的一種方式會對是否實作介面進行檢查，程式碼如下：

//以注释的形式模仿使用接口关键字
var CompositeForm =function(id , method,action) { //implements Composite , FormItem
    // do something
    this.implementsinterfaces=[&#39;Composite&#39;,&#39;FormItem&#39;]; //显式地把接口放在implementsinterfaces中
}

//检查接口是否实现
function implements(Object){
    for(var i=0 ;i< arguments.length;i++){
        var interfaceName=arguments[i];
        var interfaceFound=false;
        for(var j=0;j<Object.implementsinterfaces.length;j++){
            if(Object.implementsinterfaces[j]==interfaceName){
                interfaceFound=true;
                break;
            }
        }
        if(!interfaceFound){
            return false;
        }else{
            return true;
        }
    }
}

function AddForm(formInstance){
    if(!implements(formInstance,&#39;Composite&#39;,&#39;FormItem&#39;)){ 
        throw new Error(&#39;Object does not implements required interface!&#39;);
    }
}

登入後複製

上述代码是在方式一的基础上进行完善，在这个例子中，CompositeForm宣称自己实现了Composite和FormItem这两个接口，其做法是把这两个接口的名称加入一个implementsinterfaces的数组。显式地声明自己支持什么接口。任何一个要求其参数属性为特定类型的函数都可以对这个属性进行检查，并在所需要的接口未在声明之中时抛出错误。这种方式相对于上一种方式，多了一个强制性的类型检查。但是这种方法的缺点在于它并未保证类真正地实现了自称实现的接口，只是知道它声明自己实现了这些接口。其实类是否声明自己支持哪些接口并不重要，只要它具有这些接口中的方法就行。鸭式辩型（像鸭子一样走路并且嘎嘎叫的就是鸭子）正是基于这样的认识，它把对象实现的方法集作为判断它是不是某个类的实例的唯一标准。这种技术在检查一个类是否实现了某个接口时也可以大显身手。这种方法的背后观点很简单：如果对象具有与接口定义的方法同名的所有方法，那么就可以认为它实现了这个接口。可以使用一个辅助函数来确保对象具有所有必需的方法，代码如下：

//interface
var Composite =new Interface(&#39;Composite&#39;,[&#39;add&#39;,&#39;remove&#39;,&#39;getName&#39;]);
var FormItem=new Interface(&#39;FormItem&#39;,[&#39;save&#39;]);

//class
var Composite=function(id,method,action){

}

//Common Method
function AddForm(formInstance){
    ensureImplements(formInstance,Composite,FormItem);
    //如果该函数没有实现指定的接口，这个函数将会报错
}

登入後複製

与另外两种方式不同，这种方式无需注释，其余的各个方面都是可以强制实施的。EnsureImplements函数需要至少两个参数。第一个参数是想要检查的对象，其余的参数是被检查对象的接口。该函数检查器第一个参数代表的对象是否实现了那些接口所声明的方法，如果漏掉了任何一个，就会抛错，其中会包含被遗漏的方法的有效信息。这种方式不具备自我描述性，需要一个辅助类和辅助函数来帮助实现接口检查，而且它只关心方法名称，并不检查参数的名称、数目或类型。

四、Interface类

在下面的代码中，对Interface类的所有方法的参数都进行了严格的控制，如果参数没有验证通过，那么就会抛出异常。加入这种检查的目的就是，如果在执行过程中没有抛出异常，那么就可以肯定接口得到了正确的声明和实现。

var Interface = function(name ,methods){
    if(arguments.length!=2){
        throw new Error(&#39;2 arguments required!&#39;);
    }
    this.name=name;
    this.methods=[];
    for(var i=0;len=methods.length;i<len;i++){
        if(typeof(methods[i]!==&#39;String&#39;)){
            throw new Error(&#39;method name must be String!&#39;);
        }
        this.methods.push(methods[i]);
    }
}

Interface.ensureImplements=function(object){
    if(arguments.length<2){
        throw new Error(&#39;2 arguments required at least!&#39;);
    }
    for(var i=0;len=arguments.length;i<len;i++){
        var interface=arguments[i];
        if(interface.constructor!==Interface){
            throw new Error(&#39;instance must be Interface!&#39;);
        }
        for(var j=0;methodLength=interface.methods.length;j<methodLength;j++){
            var method=interface.methods[j];
            if(!object[method]||typeof(object[method])==&#39;function&#39;)){
                throw new Error(&#39;object does not implements method!&#39;);
            }    
        }
    }
}

登入後複製

其实多数情况下，接口并不是经常被使用的，严格的类型检查并不总是明智的。但是在设计复杂的系统的时候，接口的作用就体现出来了，这看似降低了灵活性，却同时也降低了耦合性，提高了代码的重用性。这在大型系统中是比较有优势的。在下面的例子中，声明了一个displayRoute方法，要求其参数具有三个特定的方法，通过Interface对象和ensureImplements方法来保证这三个方法的实现，否则将会抛出错误。

//声明一个接口，描述该接口包含的方法
 var DynamicMap=new Interface{&#39;DynamicMap&#39;,[&#39;centerOnPoint&#39;,&#39;zoom&#39;,&#39;draw&#39;]};

 //声明一个displayRoute方法
 function displayRoute(mapInstance){
    //检验该方法的map
    //检验该方法的mapInsstance是否实现了DynamicMap接口，如果未实现则会抛出
    Interface.ensureImplements(mapInstance,DynamicMap);
    //如果实现了则正常执行
    mapInstance.centerOnPoint(12,22);
    mapInstance.zoom(5);
    mapInstance.draw();
 }

登入後複製

下面的例子会将一些数据以网页的形式展现出来，这个类的构造器以一个TestResult的实例作为参数。该类会对TestResult对象所包含的数据进行格式化（Format）后输出，代码如下：

var ResultFormatter=function(resultObject){
     //对resultObject进行检查，保证是TestResult的实例
     if(!(resultObject instanceof TestResult)){
         throw new Error(&#39;arguments error!&#39;);
     }
     this.resultObject=resultObject;
 }

 ResultFormatter.prototype.renderResult=function(){
     var dateOfTest=this.resultObject.getData();
     var resultArray=this.resultObject.getResults();
     var resultContainer=document.createElement(&#39;p&#39;);
     var resultHeader=document.createElement(&#39;h3&#39;);
     resultHeader.innerHTML=&#39;Test Result from &#39;+dateOfTest.toUTCString();
     resultContainer.appendChild(resultHeader);

     var resultList=document.createElement(&#39;ul&#39;);
     resultContainer.appendChild(resultList);

     for(var i=0;len=resultArray.length;i<len;i++){
         var listItem=document.createElement(&#39;li&#39;);
         listItem.innerHTML=resultArray[i];
         resultList.appendChild(&#39;listItem&#39;);
     }
     return resultContainer;
 }

登入後複製

该类的构造器会对参数进行检查，以确保其的确为TestResult的类的实例。如果参数达不到要求，构造器将会抛出一个错误。有了这样的保证，在编写renderResult方法的时候，就可以认定有getData和getResult两个方法。但是，构造函数中，只对参数的类型进行了检查，实际上这并不能保证所需要的方法都得到了实现。TestResult类会被修改，致使其失去这两个方法，但是构造器中的检查依旧会通过，只是renderResult方法不再有效。

此外，构造器中的这个检查施加了一些不必要的限制。它不允许使用其他的类的实例作为参数，否则会直接抛错，但是问题来了，如果有另一个类也包含并实现了getData和getResult方法，它本来可以被ResultFormatter使用，却因为这个限制而无用武之地。

解决问题的办法就是删除构造器中的校验，并使用接口代替。我们采用这个方案对代码进行优化：

//接口的声明
var resultSet =new Interface(&#39;ResultSet&#39;,[&#39;getData&#39;,&#39;getResult&#39;]);

//修改后的方案
 var ResultFormatter =function(resultObject){
     Interface.ensureImplements(resultObject,resultSet);
     this.resultObject=resultObject;
 }

登入後複製

上述代码中，renderResult方法保持不变，而构造器却采用的ensureImplements方法，而不是typeof运算符。现在的这个构造器可以接受任何符合接口的类的实例了。