一尘不染

Javascript何时使用原型

javascript

我想了解何时在js中使用原型方法。应该一直使用它们吗?还是在某些情况下不优选使用它们和/或导致性能下降?

在此站点上搜索js中命名空间的常用方法时,似乎大多数人都使用了基于非原型的实现:简单地使用对象或函数对象来封装名称空间。

来自基于类的语言,很难不尝试绘制相似之处,并认为原型就像“类”,而我提到的命名空间实现就像静态方法。


阅读 445

收藏
2020-05-01

共1个答案

一尘不染

原型是一种 优化

很好地使用它们的一个很好的例子是jQuery库。每次使用来获取jQuery对象时$('.someClass'),该对象都有数十种“方法”。该库可以通过返回一个对象来实现:

return {
   show: function() { ... },
   hide: function() { ... },
   css: function() { ... },
   animate: function() { ... },
   // etc...
};

但这意味着内存中的每个jQuery对象都会有数十个包含相同方法的命名槽,一遍又一遍。

相反,这些方法是在原型上定义的,并且所有jQuery对象都“继承”该原型,以便以很少的运行时成本获得所有这些方法。

jQuery如何正确实现的一个至关重要的部分是,它对程序员是隐藏的。它纯粹是一种优化,而不是您使用库时要担心的事情。

JavaScript的问题在于,裸露的构造函数要求调用者记住给它们加上前缀,new否则它们通常将不起作用。没有充分的理由。jQuery通过将废话隐藏在普通函数中来实现正确的处理$,因此您不必关心对象的实现方式。

为了使您可以方便地使用指定的原型创建对象,ECMAScript 5包含一个标准函数Object.create。它的一个大大简化的版本如下所示:

Object.create = function(prototype) {
    var Type = function () {};
    Type.prototype = prototype;
    return new Type();
};

它只需要编写一个构造函数,然后使用进行调用即可new

什么时候可以避免使用原型?

与流行的OO语言(例如Java和C#)进行有用的比较。这些支持两种继承:

  • 接口 继承,在那里你implement一个interface这样的类提供了自己独特的实施接口的每一个成员。
  • 实现 继承,您可以extendclass其中提供某些方法的默认实现。

在JavaScript中,原型继承是一种 实现
继承。因此,在某些情况下(在C#或Java中)您将从基类派生以获得默认行为,然后对这些行为进行一些小的修改以通过覆盖,然后在JavaScript中,原型继承才有意义。

但是,如果您处在使用C#或Java接口的情况下,则JavaScript不需要任何特定的语言功能。无需显式声明表示接口的内容,也无需将对象标记为“实现”该接口:

var duck = {
    quack: function() { ... }
};

duck.quack(); // we're satisfied it's a duck!

换句话说,如果对象的每个“类型”都有自己的“方法”定义,则从原型继承没有任何价值。之后,这取决于您为每种类型分配多少个实例。但是在许多模块化设计中,只有一个给定类型的实例。

实际上,许多人已经提出实现继承是邪恶。就是说,如果某个类型有一些通用的操作,那么如果不将它们放到基类/超级类中,而是将它们作为普通函数暴露在某个模块中,然后将对象传递给它们,则可能会更清楚。您希望他们继续操作。

2020-05-01