JavaScriptのデザインパターン（インターフェース）を学ぶ_JavaScriptスキル

1. インターフェースの概要

1) インターフェースとは何ですか?

インターフェースは、オブジェクトが持つべきメソッドを記述する手段を提供します。これらのメソッドのセマンティクスを示すことはできますが、これらのメソッドをどのように実装するかを決定するものではありません。

2)、インターフェースの利点

• コードの再利用を促進します。

インターフェイスは、クラスがどのメソッドを実装しているかをプログラマに伝えることができるため、プログラマはこのクラスを使用することができます。

• 異なるカテゴリ間のコミュニケーション方法を安定させるのに役立ちます。
• その結果、テストとデバッグが容易になります。

JavaScript のような弱い型指定言語では、型の不一致エラーを追跡するのが困難です。インターフェイスを使用すると、オブジェクトが必要な型に見えない場合、または必要なメソッドが実装されていない場合に、有用な情報を含む明確なエラー メッセージが表示されるため、この種のエラーを見つけるのが少し簡単になります。このようにして、論理エラーをオブジェクトの構成ではなくメソッド自体に限定できます。

• インターフェイスによってコードの安定性も向上します。

インターフェイスへの変更は、それを実装するすべてのクラスに反映される必要があるためです。インターフェイスが操作を追加し、それを実装するクラスの 1 つが対応する操作を追加しない場合、すぐにエラーが表示されます。

3) インターフェースの欠点

JavaScript は、主にその弱い型の特性により、画像を表現する能力に優れた言語です。インターフェイスを使用すると、プログラム的に型の役割が確実に強化されます。これにより、言語の柔軟性が低下します。 JavaScript はインターフェースの組み込みサポートを提供していないため、他の言語の組み込み機能を模倣しようとする場合には常にある程度のリスクが伴います。

js でインターフェイスを使用する場合の最大の問題は、自分が定義したインターフェイスに他のプログラマーに準拠させることができないことです。他の言語では、インターフェイスの概念が組み込まれており、誰かがインターフェイスを実装するクラスを定義すると、コンパイラーはそのクラスが実際にインターフェイスを実装していることを確認します。 JavaScript では、手動メソッドを使用して、特定のクラスがインターフェイスを実装していることを確認する必要があります。コーディング規約とヘルパー クラスはある程度の助けにはなりますが、問題を完全に根絶することはできません。プロジェクトの他のプログラマがインターフェイスを真剣に受け止めない場合、これらのインターフェイスの使用を強制することはできません。プロジェクトの全員がインターフェイスの使用に同意し、それを検査しない限り、インターフェイスの価値の多くは実現されません。

2. JavaScript でインターフェースを模倣します

JavaScript でインターフェースを模倣する 3 つの方法: アノテーション記述方法、属性検査方法、ダックタイプ識別方法。

単一のテクニックが完璧ということはありませんが、3 つのテクニックを組み合わせることで通常は満足のいくものになります。

1)、アノテーション記述メソッド実装インターフェース

アノテーションを使用してインターフェースを模倣するのは最も簡単な方法ですが、その効果は最悪です。このアプローチは、他のページ オブジェクト言語で行われることを模倣し、インターフェイスを使用してキーワードを実装しますが、構文エラーを避けるためにキーワードをコメント内に配置します。以下のように:

//javascript中定义接口的方式有三种：
//1、注解描述的方式

 /**  
  * interface Composite{
* function add(obj);
* function remove(obj);
* function update(obj);
}

优点：程序员可以有参考
缺点：缺点一大堆，他只是一个借口的文档范畴，假如不实现
   所有的方法，程序照样可以运行，太松散了。对测试和调试难度大
*/

// Implement of interface Composite
var CompositeImpl =function(){

 /*this.add = function(obj){

  };
  this.remove = function(obj){

  };
   这种函数定义的方法，在实例化一个对象的时候，new
   一个示例，将产生一个方法，且各个实力的方法还不一样。
   所以采用下面的方法：
  */
  CompositeImpl.prototype.add = function(obj){

  }
  CompositeImpl.prototype.remove = function(obj){

  }    
  CompositeImpl.prototype.update = function(obj){
  }
}

var c1 = new CompositeImpl();
var c2 = new CompositeImpl()

alert(c1.add == c2.add)

この模倣はあまり良くありません。 Composite が実際に正しいメソッド セットを実装しているかどうかをチェックしたり、プログラム内の問題をプログラマに知らせるためにエラーをスローしたりすることはありません。結局のところ、それは主にプログラムドキュメントのカテゴリに属します。このアプローチでは、インターフェイス規則への準拠は完全に意識的な努力に依存します。

2)、属性検出メソッド実装インターフェース

この方法はより厳密です。すべてのクラスは、実装するインターフェイスを明示的に宣言しており、これらのクラスを処理したいオブジェクトはこれらの宣言をチェックできます。インターフェイス自体はまだ単なる注釈ですが、プロパティを検査することで、クラスがどのインターフェイスを実装する必要があるかを知ることができるようになりました。

/** 
  * interface Composite{
 *   function add(obj);
 *   function remove(obj);
 *   function update(obj);
 * }

 * interface FormItem{
 *   function select(obj);
 * }
 */

  // CompositeImpl implements interface Composite,FormItem
  var CompositeImpl =function(){
    //显示在类的内部，接收所实现的接口，一般来说，这是一个规范，
    // 我们项目经理：在内部类定义一个数组，名字要固定

    this.interfaceImplments = ['Composite','FormItem'];
    CompositeImpl.prototype.add = function(obj){
       alert("小平果");
  }
  CompositeImpl.prototype.remove = function(obj){

  }    
  CompositeImpl.prototype.update = function(obj){

  }
  /*CompositeImpl.prototype.select = function(obj){

  }*/
  }

  //定义函数检测，判断当前对象是否实现了所有的接口
  function checkCompositeImpl (instance){
    if (!isImplments(instance,'Composite','FormItem')) {
      throw new Error('Object cannot implements all the interface');
    };
  }

  //公用的具体检测方法（核心方法）,主要目的就是判断示例对象有没有实现相关的接口；
  function isImplments(object){
    //arguments 对象会的函数的实际对象
    for (var i = 1, len = arguments.length; i < len; i++) { //注意这里从1开始，逐个方法判断。
      var interfaceName = arguments[i];      //接收实现每一个接口的名字
      var interfaceFound = false;//判断此方法到底是实现了还是失败了？规范里定义了interfaceImplments.

      for (var j = 0;j < object.interfaceImplments.length; j++) {
        if(object.interfaceImplments[j] == interfaceName){
          interfaceFound = true;
          break;
        }
      };
       //如果没有实现，则返回false
       if (!interfaceFound) {
          return false;
       };

    }
     return true;
  }

var c1 = new CompositeImpl();
checkCompositeImpl(c1);

c1.add();

这个例子中，CompositeImpl 宣称自己实现了Composite接口，其做法是把这两个接口名称加入一个名为implementsInterfaces的数组。类显式声明自己支持什么接口。任何一个要求基于参数属于特定类型的函数都可以对这个属性进行检查，并在所需接口未在声明之列时抛出一个错误。

这种方法有几个优点。它对类所实现的接口提供了文档说明。如果需要的接口不在一个类宣称支持的接口之列，你会看到错误消息。通过利用这些错误，你可以强迫其他程序员声明这些接口。

这种方法的主要缺点在于它并未确保类真正实现了自称实现的接口。你只知道它是否说自己实现了接口。在创建一个类时声明它实现了一个接口，但后来在实现该接口所规定的方法时却漏掉其中的某一个，这种错误很常见。此时所有检查都能通过，但那个方法却不存在，这将在代码中埋下一个隐患。另外显式声明类所支持的接口也需要一些额外的工作。

3）、鸭式辨型法实现接口

其实，类是否声明自己支持哪些接口并不重要，只要它具有这些接口中的方法就行。鸭式辨型（这个名称来自James Whitomb Riley的名言：“像鸭子一样走路并且嘎嘎叫的就是鸭子”）正是基于这样的认识。它把对象实现的方法集作作为判断它是不是某个类的实例的唯一标准。这种技术在检查一个类是否实现了某个接口时也可大显向身手。这种方法背后的观点很简单：如果对象具有与接口定义的方法同名的所有方法，那么就可以认为它实现了这个接口。你可以用一个辅助函数来确保对象具有所有必需的方法:

/* 实现接口的第三种方式：鸭式辨型发实现接口，（较为完美的实现方法）
   核心思想：一个类实现接口的主要目的：把其中的方法都实现了（检测方法）
   完全面向对象 代码实现统一，实现解耦*/

//1、接口类---Class Interface ===>实例化N多个接口

/**
 *接口类的参数？几个
 * 参数1：接口名
 * 参数2：接收方法的集合（数组）
 */
var Interface = function(name , methods){
   //判断接口的参数个数
   if (arguments.length !=2) {
     throw new Error('the instance interface constructor arguments should be 2');
   };
   this.name =name;
   //this.methods = methods;
   this.methods = [];
   for (var i = 0, len = methods.length; i <len; i++) {
     if (typeof methods[i] !== "string"){
        throw new Error('the name of method is wrong');
     }
     this.methods.push(methods[i]);
   } 
}

//2、准备工作，具体的实现

//(1)实例化接口对象
var CompositeInterface = new Interface('CompositeInterface',['add','delete']);
var FormItemInterface = new Interface('FormItemInterface',['update','select']);


 //(2)具体的实现类
//CompositeImpl implments CompositionIterface FormItemIterface
var CompositeImpl = function(){

}


//(3)实现接口的方法 implements methods
CompositeImpl.prototype.add = function(obj){
  alert("add");
}
CompositeImpl.prototype.delete = function(obj){
  alert("delete");
}     
CompositeImpl.prototype.update = function(obj){
  alert("update");
}
/*CompositeImpl.prototype.select = function(obj){
  alert("select");
}*/


//3、检验接口里的方法
//如果检测通过，不做任何操作；不通过，则抛出异常。
//这个方法的目的就是 检测方法的

Interface.ensureImplements =function(object){
   //如果接受参数长度小于2 ，证明还有任何实现的接口
   if (arguments.length < 2) {
     throw new Error('The Interface has no implement class');
   };

   //获得接口的实例对象
  for (var i = 1, len= arguments.length; i < len; i++) {
     var instanceInterface =arguments[i];
     //判断参数是否为 接口类的类型
     if (instanceInterface.constructor !==Interface) {
        throw new Error('The arguments constructor is not Interface Class');
     };

     for (var j = 0, len2 =instanceInterface.methods.length ; j <len2; j++ ) {
        //用一个临时变量 ，接收每个方法的名字（注意为字符串类型）
        var methodName = instanceInterface.methods[j];
        //object[key] 获得方法
        if (!object[methodName] || typeof object[methodName] !== 'function')
        {
          throw new Error('the method"'+ methodName+'"is not found');
        }
     }
   }
}

var c1 =new CompositeImpl();
Interface.ensureImplements(c1,CompositeInterface,FormItemInterface);
c1.add();

与另外两种方法不同，这种方法并不借助注释。其各个方面都是可以强制实施的。ensureImplements函数需要至少两个参数。第一个参数是想要检查的对象。其余参数是据以对那个对象进行检查的接口。该函数检查其第一个参数代表的对象是否实现了那些接口所声明的所有方法。如果发现漏掉了任何一个方法，它就会抛出错误，其中包含了所缺少的那个方法和未被正确实现的接口的名称等有用信息。这种检查可以用在代码中任何需要确保某个对象实现了某个接口的地方。在本例中，addForm函数仅当一个表单对象支持所有必要的方法时才会对其执行添加操作。

尽管鸭式辨型可能是上述三种方法中最有用的一种，但它也有一些缺点。这种方法中，类并不声明自己实现了哪些接口，这降低了代码的可重用性，并且也缺乏其他两种方法那样的自我描述性。它需要使用一个辅助类Interface和一个辅助函数ensureImplements。而且，它只关心方法的名称，并不检查其参数的名称、数目或类型。

3、Interface类的使用场合

严格的类型检查并不总是明智的。许多js程序员根本不用接口或它所提供的那种检查，也照样一干多年。接口在运用设计模式实现复杂系统的时候最能体现其价值。它看似降低javascript的灵活性，而实际上，因为使用接口可以降低对象间的耦合程度，所以它提高了代码的灵活性。接口可以让函数变得更灵活，因为你既能向函数传递任何类型的参数，又能保证它只会使用那些具有必要方法的对象。

4、Interface类的用法

判断代码中使用接口是否划算是最重要的一步。对于小型的、不太费事的项目来说，接口的好处也许并不明显，只是徒增其复杂度而已。你需要自行权衡其利弊。如果认为在项目中使用接口利大于弊，那么可以参照如下使用说明：
1）、 将Interface类纳入HTML文件。
2）、 逐一检查代码中所有以对象为参数的方法。搞清代码正常运转要求的这些对象参数具有哪些方法
3）、 为你需要的每一个不同的方法集创建一个Interface对象。
4）、 剔除所有针对构造器显式检查。因为我们使用是鸭式辨型，所以对象的类型不再重要。
5）、 以Interface.ensureImplements取代原来的构造器检查。

示例
假设你要创建一个类，它可以将一些自动化测试结果转化为适于在网页上查看的格式。该类的构造器以一个TestResult类的实例为参数。它会应客户的请求对这个TestResult对象所封装的数据进行格式化，然后输出。
原始定义：

 var ResultFormatter =function(resultsObject){
    if(!(resultsObject instanceof TestResult)){
      throw newError("ResultsFormatter:constructor requires an instance of TestResult asan argument.")
    }
    this.resultsObject = resultsObject;
  }
  ResultFormatter.prototype.renderResults =function(){
    var dateOfTest = this.resultsObject.getDate();
    var resultsArray =this.resultsObject.getResults();
    var resultsContainer =document.createElement('div');
    var resultsHeader =document.createElement("h3");
    resultsHeader.innerHTML = "TestResults from "+dateOfTest.toUTCString();
    resultsContainer.appendChild(resultsHeader);
    var resultList =document.createElement("ul");
    resultsContainer.appendChild(resultList);
    for(var i=0,len=resultsArray.length;i<len;i++){
      var listItem=document.createElement('li');
      listItem.innerHTML =resultsArray[i];
      resultList.appendChild(listItem);
    }
    return resultsContainer;
  }

该类的构造器会对参数进行检查，以确保其的确为TestResult类的实例。如果参数达不到要示，构造器将抛出一个错误。有了这样的保证，在编写renderResults方法时，你就可以认定有getDate和getResults这两个方法可供使用。实际上这并不能保证所需要的方法得到了实现。TestResult类可能会被修改，致使其不再拥有getDate()方法。在此情况下，构造器中的检查仍能通过，但renderResults方法却会失灵。

此外，构造器的这个检查施加了一些不必要的限制。它不允许使用其他类的实例作为参数，哪怕它们原本可以如愿发挥作用。例如，有一个名为WeatherData在也拥有getDate和getResults这两个方法。它本来可以被ResultFormatter类用得好好的。但是那个显式类型检查会阻止使用WeatherData类的任何实例。
问题解决办法是删除那个使用instanceOf的检查，并用接口代替它。首先，我们需要创建这个接口：

//ResultSetInterface.
var ResultSet =new Interface(“ResultSet”,[‘getDate','getResults']);

上面的这行代码创建了一个Interface对象的新实例。第一个参数是接口的名称，第二个参数是一个字符串数组，其中的每个字符串都是一个必需的方法名称。有了这个接口之后，就可以用接口检查替代instanceOf检查了

var ResultFormatter = function(resultsObject){
 Interface.ensureImplements(resultsObject,ResultSet);
 this.resultsObject = resultsObject;
}
ResultFormatter.prototype.renderResults= function(){
 …
}

renderResults方法保持不变。而构造器则被改为使用ensureImplements方法而不是instanceof运算符。现在构造器可以接受WeatherData或其他任何实现所需要方法的类的实例。我们只修改了几行ResultFormatter类代码，就让那个检查变得更准确，而且更宽容。

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

• 工厂模式
• 组合模式
• 装饰模式
• 命令模式

以上就是JavaScript设计模式中接口的实现相关介绍，希望对大家的学习有所帮助。