使用jQuery对象的OOP :改变jQuery数组的原型与创建自己的对象树

Question

引言

对于我的新工作，我必须编写一个经典的下拉菜单示例，它是高度可访问的(通过鼠标和键盘)，并且与屏幕阅读器兼容(通过正确地管理WAI属性和状态)。我的团队由“正常”的人和身体有残疾的人组成，他们说，直到现在他们才能找到一个完全无障碍的下拉菜单，所以我们正在尝试创建自己的菜单给客户。

嗯，我来自Rails背景，直到现在还没有编写复杂的JavaScript代码，所以我尝试将我从Ruby知识应用到JS世界。由于我对CoffeeScript相当了解，而且它在后台提供了一些魔力，使得使用类和继承变得很容易(尽管JS是一种对象驱动的语言，并且没有类)，所以我坚持使用CoffeeScript而不是普通的JS。

我正在尝试设置一些与下拉菜单类似的适当的对象树：

• 有一个Item类。
• 有一个ParentItem类继承自Item。
• 有一个RootParentItem类继承自ParentItem。

这样，所有根项都是RootParentItem类型，所有其他父项(持有自己的子菜单的项目)都是ParentItem类型，所有“真实”菜单项(指向网站中某个位置的链接)都是Item类型。

通过设置这个适当的对象树，我认为根据项目的类型，处理不同的键操作、鼠标操作等是非常简单和合理的。这有助于防止冗长的过程代码，这是我在其他提供类似功能的JS库上看到的。

下面是我当前工作的一个例子：http://codepen.io/jmuheim/pen/fAjcx

现在，经过一些思考，我问了我一个问题:创建自己的对象树是否合理，而背景中有很多jQuery数组，并将它们保存在对象的变量中？有一个很好的树结构让人觉得有些奇怪，但是总是使用一个完全相同结构的“阴影”，比如: jQuery数组。

如前所述，我来自一个高度面向对象的Ruby世界。我在JavaScript世界中没有任何清洁编码实践/模式的经验，所以：

• 你认为我的尝试合理吗？
• 有没有一种更清洁(更被公众接受)的方法来做到这一点？也许直接处理jQuery数组的原型会更合理呢？然而，如何做到这一点呢？
• 还有其他关于我的JS编码风格的评论吗？

Answer 1

我认为你的继承模式是反向的。听起来，您希望"Item“成为”叶子“子类，但您说的是"ParentItem从Item继承的”。项目实际上应该从ParentItem继承等等。

在面向对象设计方面，它实际上取决于如何使用“背景中”的数组。这些是每个类实例的唯一列表吗？它们是在所有类实例之间共享的静态列表还是仅在一种类型的类实例之间共享的静态列表？如果是前者，为每个实例存储这些数组的内部成员变量是有意义的。如果是后者，您实际上是在谈论静态成员变量，用经典的OO术语来说。这可以通过将静态成员附加到constructor对象作为普通属性(并以此形式访问)来实现，而不是在原型上，或者在构造函数中分配给"this“。举个例子：

function A(name) {
this.name = name;
}

A.prototype.doStuff = function() {
 A.staticList.push(this.name);
};

A.staticList = [];

var x = new A('foo');
var y = new A('bar');

x.doStuff();
y.doStuff();

A.staticList; // contains ['foo', 'bar']

Answer 2

所有的“真正”菜单项(指向网站中某个位置的链接)都是Item类型的。

我会考虑为它们使用RealItem或LinkItem类，这些类也是从Item继承的。

创建自己的对象树是否合理，而背景中有很多jQuery数组，并将它们保存在对象的变量中？

是。这就是大多数使用MVC模型的应用程序所做的事情--视图组件控制DOM，并将对它的引用(或jQuery包装器)作为类中的属性/变量。

有没有一种更清洁(更被公众接受)的方法来做到这一点？也许直接处理jQuery数组的原型会更合理呢？

我不认为那会更干净。

然而，如何做到这一点呢？

是的，你can inherit from jQuery collections，但我不推荐它。

还有其他关于我的JS编码风格的评论吗？

如果您使用一些函数式编程实践，代码可能会变得更枯燥，但我认为它很好。