JavaScript의 인터페이스 코드에 대한 자세한 설명에 대한 간략한 토론

1. 인터페이스란 무엇입니까

인터페이스는 객체지향 자바스크립트 프로그래머의 도구 상자에서 가장 유용한 도구 중 하나입니다. 디자인 패턴에서 제안하는 재사용 가능한 객체지향 디자인의 원칙 중 하나는 "구현 프로그래밍이 아닌 인터페이스를 위한 프로그래밍"인데, 이를 인터페이스 지향 프로그래밍이라고 부르는 개념의 중요성은 분명합니다. 그런데 문제는 자바스크립트의 세계에는 인터페이스를 생성하거나 구현하는 내장 메소드가 없고, 객체가 다른 객체와 동일하게 구현하는지 판단할 수 있는 메소드 집합이 없어 사용하기 어렵다는 점이다. 다행스럽게도 JavaScript는 유연성이 뛰어나 기존 객체 지향 인터페이스를 쉽게 시뮬레이션하고 이러한 기능을 추가할 수 있습니다. 인터페이스는 객체가 어떤 메소드를 가져야 하는지 설명하는 수단을 제공하지만 이러한 메소드의 의미를 나타낼 수는 있지만 특정 구현을 포함하지는 않습니다. 이 도구를 사용하면 객체가 제공하는 속성을 기준으로 객체를 그룹화할 수 있습니다. 예를 들어, A와 B 및 인터페이스 I의 경우 A 객체와 B 객체가 매우 다르더라도 둘 다 I 인터페이스를 구현하는 한 A와 B는 A.I(B) 메서드에서 서로 바꿔 사용할 수 있습니다. B.I(A) 같은 거죠. 인터페이스를 사용하여 서로 다른 클래스 간의 공통성을 개발할 수도 있습니다. 원래 특정 클래스를 매개변수로 요구하는 함수가 특정 인터페이스를 매개변수로 요구하는 함수로 변경되면, 인터페이스를 구현하는 모든 객체를 매개변수로 전달할 수 있으므로, 관련되지 않은 모든 객체는 서로 매개변수로 전달될 수도 있습니다. 객체도 동일하게 처리될 수 있습니다.

2. 인터페이스의 장점과 단점

설정된 인터페이스는 자체 설명적이며 코드 재사용성을 높일 수 있습니다. 인터페이스는 외부 클래스에 어떤 메서드가 필요한지 알려주는 일종의 정보를 제공할 수 있습니다. 구현되었습니다. 또한 서로 다른 클래스 간의 통신 방식을 안정화하고 두 객체를 상속하는 과정에서 발생하는 문제를 줄이는 데 도움이 됩니다. 이는 디버깅에도 도움이 됩니다. JavaScript와 같은 약한 유형의 언어에서는 인터페이스를 사용할 때 문제가 발생하면 더 명확한 오류 메시지가 표시됩니다. 물론 인터페이스에 단점이 전혀 없는 것은 아닙니다. 인터페이스를 광범위하게 사용하면 약한 유형의 언어로서의 유연성이 어느 정도 약화됩니다. 반면에 JavaScript는 인터페이스에 대한 기본 지원을 제공하지 않으며 기존 객체를 시뮬레이션할 뿐입니다. 이는 본질적으로 유연한 JavaScript를 제어하기 어렵게 만듭니다. 또한 인터페이스를 구현하는 방식에 관계없이 추가 메서드 호출로 인한 오버헤드로 인해 성능에 영향을 미칩니다. 인터페이스 사용의 가장 큰 문제점은 다른 강력한 유형의 언어와 달리 JavaScript가 인터페이스 규칙을 준수하지 않으면 컴파일에 실패한다는 것입니다. 협업 개발 환경에서는 위의 문제를 효과적으로 피할 수 있습니다. 오류가 발생하지 않고 손상될 가능성이 매우 높으며 이는 통제할 수 없습니다.

객체 지향 언어에서 인터페이스를 사용하는 방식은 일반적으로 유사합니다. 인터페이스에 포함된 정보는 클래스가 구현해야 하는 메서드와 이러한 메서드의 서명을 설명합니다. 클래스 정의는 이러한 인터페이스를 구현한다는 것을 명시적으로 명시해야 합니다. 그렇지 않으면 컴파일되지 않습니다. 분명히 JavaScript에서는 동일한 작업을 수행할 수 없습니다. 인터페이스와 구현 키워드가 없고 런타임 시 인터페이스가 계약을 따르는지 확인하지 않기 때문입니다. 하지만 보조 메서드와 명시적 확인을 통해 대부분의 기능을 모방할 수 있습니다.

3. 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=['Composite','FormItem']; //显式地把接口放在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('Composite',['add','remove','getName']);
var FormItem=new Interface('FormItem',['save']);

//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('2 arguments required!');
    }
    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{'DynamicMap',['centerOnPoint','zoom','draw']};

 //声明一个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('arguments error!');
     }
     this.resultObject=resultObject;
 }

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

     var resultList=document.createElement('ul');
     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('ResultSet',['getData','getResult']);

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

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

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

<1>工厂模式：对象工厂所创建的具体对象会因具体情况而不同。使用接口可以确保所创建的这些对象可以互换使用，也就是说对象工厂可以保证其生产出来的对象都实现了必需的方法；

<2>组合模式：如果不使用接口就不可能使用这个模式，其中心思想是可以将对象群体与其组成对象同等对待。这是通过接口来做到的。如果不进行鸭式辩型或类型检查，那么组合模式就会失去大部分意义;

<3>데코레이터 패턴: 데코레이터는 다른 개체에 대한 래퍼를 투명하게 제공하여 작동합니다. 이는 다른 객체의 인터페이스와 정확히 동일한 인터페이스를 구현함으로써 달성됩니다. 외부 세계에서는 데코레이터와 데코레이터가 래핑하는 객체 사이에 차이가 없으므로 인터페이스를 사용하여 생성된 데코레이터가 필요한 메서드를 구현하는지 확인하세요.

<4> 명령 모드: 코드의 모든 명령 개체는 동일한 메서드 배치(예: run, ecxute, do 등)를 구현합니다. 인터페이스를 사용하면 이러한 명령 개체를 실행하지 않고 생성된 클래스는 이러한 개체가 무엇인지 알 필요가 없습니다. 그들 모두가 인터페이스를 올바르게 구현한다는 것을 알아 두십시오. 이를 통해 높은 수준의 모듈성과 낮은 결합성을 갖춘 API를 생성할 수 있습니다.

위 내용은 JavaScript의 인터페이스 코드에 대한 간략한 설명입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!