学习JavaScript设计模式(接口)(javascript学习指南)

推荐整理分享学习JavaScript设计模式(接口)(javascript学习指南)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:javascript课设,javascript教程chm,javascript教程chm,javascript设计,javascript教程 csdn,javascript教程 csdn,javascript教程chm,javascript课设,内容如对您有帮助，希望把文章链接给更多的朋友！

1、接口概述

1）、什么是接口？

接口是提供了一种用以说明一个对象应该具有哪些方法的手段。尽管它可以表明这些方法的语义，但它并不规定这些方法应该如何实现。

2）、 接口之利

接口可以告诉程序员一个类实现了哪些方法，从而帮助其使用这个类。

在javascript这种弱类型语言中，类型不匹配错误很难跟踪。使用接口可以让这种错误的查找变午更容易一点，因为此时如果一个对象不像所要求的类型，或者没有实现必要的方法，那么你会得到包含有用信息的明确的错误提示。这样一来，逻辑错误可以被限制在方法自身，而不是在对象构成之中。

因为对接口的任何改变在所有实现它的类都必须体现出来。如果接口添加了一个操作，而某个实现它的类并没有相应的添加这个操作，那么你肯定会立即见到一个错误。

3）、接口之弊

javascript是一种具有极强表现图片的语言，这主要得益于其弱类型的特点。而接口的使用则一定程序上强化了类型的作用。这降低了语言的灵活性。javascript并没有提供对接口的内置支持，而试图模仿其它语言内置的功能总会有一些风险。

js中接口使用的最大问题在于，无法强迫其他程序员遵守你定义的接口。在其它语言中，接口的概念是内置的，如果某人定义了实现一个接口的类，那么编译器会确保该类的确实现了这个接口。而在javascript中则必须用手工的办法保证某个类实现了一个接口。编码规范和辅助类可以提供一些帮助，但无法彻底根除这个问题。如果项目的其他程序员不认真对待接口，那么这些接口的使用是无法得到强制性保证的。除非项目的所有人都同意使用接口并对其进行检查，否则接口的很多价值都无从体现。

2、在javascript中模仿接口

javascript中模仿接口的三种方法：注解描述法、属性检查法、鸭式辨型法。

没有哪种技术是完美的，但三者结合使用基本上可以令人满意。

1）、注释描述法实现接口

用注释模仿接口是最简单的方法，但效果却是最差的。这种方法模仿其他页面对象语言中的做法，使用了interface和implements关键字，但把它们放在注释中，以免引起语法错误。如下：

这种模仿并不是很好。它没有为确保Composite真正实现了正确的方法集而进行检查，也不会抛出错误以告知程序员程序中的问题。说到底它主要还是属于程序文档范畴。在这种做法中，对接口约定的遵守完全依靠自觉。

2）、属性检测法实现接口

这种方法更严谨一点。所有类都明确地声明自己实现了哪些接口，那些想与这些类打交道的对象可能针对这些声明进行检查。那些接口自身仍然只是注释，但现在你可以通过检查一个属性得知某个类自称实现了什么接口。

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

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

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

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

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

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

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

3、Interface类的使用场合

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

4、Interface类的用法

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

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

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

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

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

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

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