这种 JavaScript 编码风格有什么问题？（闭包与原型）答案

【问题标题】：What's wrong with this style of coding JavaScript? (closures vs. prototypes)这种 JavaScript 编码风格有什么问题？（闭包与原型）
【发布时间】：2013-02-06 01:11:42
【问题描述】：

我们一直在讨论如何最好地处理我们的 JS 应用程序中的对象，研究 Stoyan Stefanov 的书，阅读关于“新”、“这个”、“原型”、闭包等的无休止的 SO 帖子。（事实上有这么多，而且他们有很多相互竞争的理论，这表明没有完全明显的答案）。

所以让我们假设我们不关心私人数据。我们满足于相信用户和开发人员不会在我们定义的方式之外乱搞对象。

考虑到这一点，这种技术有什么问题（除了它似乎违背了数十年的 OO 风格和历史）？

// namespace to isolate all PERSON's logic
var PERSON = {};

// return an object which should only ever contain data.
// The Catch: it's 100% public

PERSON.constructor = function (name) {
     return {
         name: name
     } 
}

// methods that operate on a Person
// the thing we're operating on gets passed in

PERSON.sayHello = function (person) {
     alert (person.name); 
}

var p = PERSON.constructor ("Fred");
var q = PERSON.constructor ("Me");

// normally this coded like 'p.sayHello()'
PERSON.sayHello(p);
PERSON.sayHello(q);

显然：

没有什么可以阻止某人在邪恶中变异“p” 方式，或者只是 PERSON 的逻辑最终遍布各处。（规范的“新技术”也是如此）。
将“p”传递给您使用的每个函数将是一个小麻烦想用它。
这是一种奇怪的方法。

但是这些足够好的理由来驳回它吗？积极的一面：

它高效，因为（可以说）与重复函数声明的闭包相反。
看起来非常简单易懂，而不是摆弄 “这个”无处不在。

关键是隐私保护。我知道我会为此受到抨击，但是，寻找任何反馈。干杯。

【问题讨论】：

用这种方法有一个人构造函数有什么意义吗？只需使用鸭子打字PERSON.sayHello({name: "Fred"})
我最喜欢的 js 方法 - 1) 使用咖啡脚本，不是万能药，而是给人一种 OO 类的错觉 - 2) 来自“JavaScript: The Good Parts” pg 52 - amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/… 的函数式构造函数模板
@house9 但万灵药？类只是语法和在预编译范式中更有意义的语法。为什么人们在尝试学习 JS 时会如此沉迷于它们？理解 JS 的关键是理解 JS 函数。在那之后，构造函数是孩子的游戏。 JS 的面向对象编程方法没有任何问题。与通常与之相比的预编译语言相比，在 JS 中构建大多数面向 OOP 的模式所需的代码要少得多。

标签： javascript closures prototype

【解决方案1】：

它本质上没有任何问题。但它确实放弃了使用 Javascript 原型系统所固有的许多优点。

除了它是一个对象字面量之外，您的对象对自身一无所知。所以instanceof 不会帮助你识别它的来源。只使用鸭式打字会卡住。
您的方法本质上是命名空间静态函数，您必须通过将对象作为第一个参数传入来重复自己。通过拥有一个原型对象，您可以利用动态调度，以便p.sayHello() 可以为PERSON 或ANIMAL 做不同的事情，这取决于Javascript 知道的类型。这是多态性的一种形式。您的方法要求您在每次调用方法时命名（并且可能会出错）类型。
您实际上不需要constructor 函数，因为函数已经是对象。您的PERSON 变量也可以是构造函数。

您在这里所做的是创建一个模块模式（如命名空间）。

这是另一种模式，它保留了你所拥有的，但提供了上述优势：

function Person(name)
{
    var p = Object.create(Person.prototype);
    p.name = name; // or other means of initialization, use of overloaded arguments, etc.
    return p;
}
Person.prototype.sayHello = function () { alert (this.name); }

var p = Person("Fred"); // you can omit "new"
var q = Person("Me");
p.sayHello();
q.sayHello();
console.log(p instanceof Person); // true
var people = ["Bob", "Will", "Mary", "Alandra"].map(Person);
        // people contains array of Person objects

【讨论】：

我很抱歉没有尽快接受，非常感谢您的出色回复。干杯！

【解决方案2】：

是的，我真的不明白你为什么要试图避开构造函数方法，或者当构造函数本身是优雅的时，为什么他们甚至觉得有必要在函数构造函数（Object.create 和很快的类）上添加语法糖，灵活且完全合理的 OOP 方法，无论像 Crockford 这样的人给出了多少不喜欢它们的蹩脚理由（因为人们忘记使用 new 关键字 - 严重吗？）。 JS 是高度功能驱动的，它的 OOP 机制也不例外。 IMO，接受它总比躲避它要好。

首先，您的积分列在“明显”下

在 JavaScript 中几乎不值得一提。高度可变性是设计使然。我们不怕我们自己或其他 JavaScript 开发人员。私有与公共范式没有用处，因为它可以保护我们免于愚蠢，而是因为它可以更容易地理解其他开发人员代码背后的意图。
调用的努力不是问题。当你不清楚你为什么做了你在那里做过的事情时，麻烦就来了。我真的看不出你想要达到什么核心语言方法对你没有更好的效果。
这是 JavaScript。多年来，除了 JS 开发人员之外，所有人都觉得很奇怪。如果您找到一种更好的方法来解决给定领域中的问题，而不是更典型的解决方案，请不要担心。在尝试替换它之前，请确保您了解更典型方法的要点，就像许多人从其他语言范式转向 JS 时所做的那样。用 JS 做一些琐碎的事情很容易，但是一旦你到了想要获得更多 OOP 驱动的地步，尽你所能了解核心语言的工作原理，这样你就可以对流行的观点提出更多的怀疑。那些以副业为生的人让 JavaScript 变得比实际情况更可怕，更充满致命的诱杀装置。

现在你在“积极方面”下的观点

首先，重复的函数定义实际上只是在繁重的循环场景中需要担心的事情。如果您定期以足够快的速度生成足够多的对象，以使非原型化公共方法定义成为性能问题，那么无论如何，您可能会在短时间内遇到非平凡对象的内存使用问题。然而，我用过去时说，因为无论哪种方式，它都不再是一个真正相关的问题。在现代浏览器中，由于现代 JIT 编译器的工作方式，在其他函数中定义的函数实际上通常会提高性能。无论您支持什么浏览器，每个对象定义几个函数都不是问题，除非您期望有数万个对象。
关于简单易懂的问题，这不是我的问题，因为我看不出你在这里获得了什么胜利。现在，我不必使用一个对象，而是必须同时使用该对象和它的伪构造函数.如果我是您的代码库的新手，我会浪费大量时间试图弄清楚您为什么这样做以避免打破我不理解的其他问题。

我的问题是：

为什么不首先在构造函数中添加对象字面量中的所有方法呢？那里没有性能问题，而且从来没有真正存在过，所以唯一可能的胜利是您希望能够在使用它创建新对象后向人员添加新方法，但这就是我们在适当的构造函数上使用原型的原因（顺便说一句，原型方法非常适合旧浏览器中的内存，因为它们只定义一次）。

如果你必须不断地传递对象以便方法知道属性是什么，你为什么还要对象呢？为什么不只是期望具有某些属性的简单数据结构类型对象的函数呢？它不再是真正的 OOP。

但我的主要批评点

您错过了 OOP 的要点，这是 JavaScript 在不向人们隐藏方面比大多数语言做得更好。考虑以下几点：

function Person(name){
    //var name = name; //<--this might be more clear but it would be redundant
    this.identifySelf = function(){ alert(name); }
}

var bob = new Person();
bob.identifySelf();

现在，在不覆盖对象或方法的情况下更改 bob 标识的名称，这两种操作只有在您明确不想使用最初设计和构造的对象时才要做。你当然不能。这让任何看到这个定义的人都清楚地知道，在这种情况下，名称实际上是一个常数。在更复杂的构造函数中，它将确定唯一允许更改或修改名称的是实例本身，除非用户添加了一个非验证的 setter 方法，这将是愚蠢的，因为这基本上会（看着你的 Java Enterprise Beans）谋杀OOP 的核心目的。

分工明确是关键

暂时忘记他们在每本书中放置的关键词，并思考重点是什么。在 OOP 之前，一切都只是一堆函数和所有这些函数所作用的数据结构。使用 OOP，您通常拥有一组与一组数据捆绑在一起的方法，而这些数据实际上只有对象本身会发生变化。

所以让我们说输出出了点问题：

在我们严格的程序堆函数中，可能会弄乱该数据的手数没有真正的限制。我们可能有很好的错误处理能力，但一个函数可能会以这样一种方式分支，使得原始罪魁祸首难以追查。
在适当的 OOP 设计中，数据通常位于对象看门人之后，我知道实际上只有一个对象可以对更改负责。

对象在大部分时间都暴露了所有数据，实际上只比旧的程序方法稍微好一点。真正做的只是给你一个名字来分类松散相关的方法。

关于“这个”的废话

我从来没有理解过对“this”关键字的过度关注是混乱和混乱的。这真的没什么大不了的。 'this' 标识您正在使用的实例。就是这样。如果该方法不作为属性调用，则它不会知道要查找的实例，因此它默认为全局对象。那是愚蠢的（未定义会更好），但是在这种情况下它不能正常工作应该是在一种语言中可以预期的，其中函数也像数据一样可移植并且可以很容易地附加到其他对象。在以下情况下在函数中使用“this”：

它被定义为实例的属性并被调用。
它作为事件处理程序传递（它将作为被侦听事物的成员调用它）。
您正在使用 call 或 apply 方法将其作为某个其他对象的属性暂时调用，而不是这样分配。

但请记住，真正重要的是召唤。将公共方法分配给某个 var 并从该 var 调用将执行全局操作或在严格模式下引发错误。在不作为对象属性引用的情况下，函数只真正关心它们在其中定义的范围（它们的闭包）以及您传递给它们的参数。

【讨论】：