凯尔-辛普森的OLO模式与原型设计模式的比较[英] Kyle Simpson's OLOO Pattern vs Prototype Design Pattern

问题描述

Does Kyle Simpson's "OLOO (Objects Linking to Other Objects) Pattern" differ in any way from the the Prototype design pattern? Other than coining it by something that specifically indicates "linking" (the behavior of prototypes) and clarifying that there's no to "copying" happening here (a behavior of classes), what exactly does his pattern introduce?

Here's an example of Kyle's pattern from his book, "You Don't Know JS: this & Object Prototypes":

var Foo = {
    init: function(who) {
        this.me = who;
    },
    identify: function() {
        return "I am " + this.me;
    }
};

var Bar = Object.create(Foo);

Bar.speak = function() {
    alert("Hello, " + this.identify() + ".");
};

var b1 = Object.create(Bar);
b1.init("b1");
var b2 = Object.create(Bar);
b2.init("b2");

b1.speak(); // alerts: "Hello, I am b1."
b2.speak(); // alerts: "Hello, I am b2."

推荐答案

what exactly does his pattern introduce?

OLOO embraces the prototype chain as-is, without needing to layer on other (IMO confusing) semantics to get the linkage.

So, these two snippets have the EXACT same outcome, but get there differently.

Constructor Form:

function Foo() {}
Foo.prototype.y = 11;

function Bar() {}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.z = 31;

var x = new Bar();
x.y + x.z;  // 42

OLOO Form:

var FooObj = { y: 11 };

var BarObj = Object.create(FooObj);
BarObj.z = 31;

var x = Object.create(BarObj);
x.y + x.z;  // 42

In both snippets, an x object is [[Prototype]]-linked to an object (Bar.prototype or BarObj), which in turn is linked to third object (Foo.prototype or FooObj).

The relationships and delegation are identical between the snippets. The memory usage is identical between the snippets. The ability to create many "children" (aka, many objects like x1 through x1000, etc) is identical between the snippets. The performance of the delegation (x.y and x.z) is identical between the snippets. The object creation performance is slower with OLOO, but sanity checking that reveals that the slower performance is really not an issue.

What I argue OLOO offers is that it's much simpler to just express the objects and directly link them, than to indirectly link them through the constructor/new mechanisms. The latter pretends to be about classes but really is just a terrible syntax for expressing delegation (side note: so is ES6 class syntax!).

OLOO is just cutting out the middle-man.

Here's another comparison of class vs OLOO.

其他推荐答案

I read Kyle's book, and I found it really informative, particularly the detail about how this is bound.

Pros:

For me, there a couple of big pros of OLOO:

1. Simplicity

OLOO relies on Object.create() to create a new object which is [[prototype]]-linked to another object. You don't have to understand that functions have a prototype property or worry about any of the potential related pitfalls that come from its modification.

2. Cleaner syntax

This is arguable, but I feel the OLOO syntax is (in many cases) neater and more concise than the 'standard' javascript approach, particularly when it comes to polymorphism (super-style calls).

Cons:

I think there is one questionable bit of design (one that actually contributes to point 2 above), and that is to do with shadowing:

In behaviour delegation, we avoid if at all possible naming things the same at different levels of the [[Prototype]] chain.

The idea behind this is that objects have their own more specific functions which then internally delegate to functions lower down the chain. For example, you might have a resource object with a save() function on it which sends a JSON version of the object to the server, but you may also have a clientResource object which has a stripAndSave() function, which first removes properties that shouldn't be sent to the server.

The potential problem is: if someone else comes along and decides to make a specialResource object, not fully aware of the whole prototype chain, they might reasonably* decide to save a timestamp for the last save under a property called save, which shadows the base save() functionality on the resource object two links down the prototype chain:

var resource = {
  save: function () { 
    console.log('Saving');
  }
};

var clientResource = Object.create(resource);

clientResource.stripAndSave = function () {
  // Do something else, then delegate
  console.log('Stripping unwanted properties');
  this.save();
};

var specialResource = Object.create( clientResource );

specialResource.timeStampedSave = function () {
  // Set the timestamp of the last save
  this.save = Date.now();
  this.stripAndSave();
};

a = Object.create(clientResource);
b = Object.create(specialResource);

a.stripAndSave();    // "Stripping unwanted properties" & "Saving".
b.timeStampedSave(); // Error!

This is a particularly contrived example, but the point is that specifically not shadowing other properties can lead to some awkward situations and heavy use of a thesaurus!

Perhaps a better illustration of this would be an init method - particularly poignant as OOLO sidesteps constructor type functions. Since every related object will likely need such a function, it may be a tedious exercise to name them appropriately, and the uniqueness may make it difficult to remember which to use.

_{*Actually it's not particularly reasonable (lastSaved would be much better, but it's just an example.)}

其他推荐答案

The discussion in "You Don't Know JS: this & Object Prototypes" and the presentation of the OLOO is thought-provoking and I have learned a ton going through the book. The merits of the OLOO pattern are well-described in the other answers; however, I have the following pet complaints with it (or am missing something that prevents me from applying it effectively):

1

When a "class" "inherits" another "class" in the classical pattern, the two function can be declared similar syntax ("function declaration" or "function statement"):

function Point(x,y) {
    this.x = x;
    this.y = y;
};

function Point3D(x,y,z) {
    Point.call(this, x,y);
    this.z = z;
};

Point3D.prototype = Object.create(Point.prototype);

In contrast, in the OLOO pattern, different syntactical forms used to define the base and the derived objects:

var Point = {
    init  : function(x,y) {
        this.x = x;
        this.y = y;
    }
};


var Point3D = Object.create(Point);
Point3D.init = function(x,y,z) {
    Point.init.call(this, x, y);
    this.z = z;
};

As you can see in the example above the base object can be defined using object literal notation, whereas the same notation can't be used for the derived object. This asymmetry bugs me.

2

In the OLOO pattern, creating an object is two steps:

1. call Object.create

2. call some custom, non standard method to initialize the object (which you have to remember since it may vary from one object to the next):

    var p2a = Object.create(Point);
   
    p2a.init(1,1);
   

In contrast, in the Prototype pattern you use the standard operator new:

var p2a = new Point(1,1);

3

In the classical pattern I can create "static" utility functions that don't apply directly to an "instant" by assigning them directly to the "class" function (as opposed to its .prototype). E.g. like function square in the below code:

Point.square = function(x) {return x*x;};

Point.prototype.length = function() {
    return Math.sqrt(Point.square(this.x)+Point.square(this.y));
};

In contrast, in the OLOO pattern any "static" functions are available (via the [[prototype]] chain) on the object instances too:

var Point = {
    init  : function(x,y) {
        this.x = x;
        this.y = y;
    },
    square: function(x) {return x*x;},
    length: function() {return Math.sqrt(Point.square(this.x)+Point.square(this.y));}
};