处理API设计和OO糖

时间:2011-10-20 11:38:17

标签: javascript api

介绍性阅读:

按照上述模式,我创建了库/ API,如下所示

var Proto = {
  constructor: function () {
    this.works = true;
  },
  method: function () {
    return this.works;
  }
};

现在,对于库用户与我的原型(不提供工厂功能)进行交互,他们必须实例化并初始化对象

// instantiate
var p = Object.create(Proto);
// initialize
p.constructor();

这是一种迫使用户实例化和初始化对象的不友好且冗长的方式。

个人因为我在我的所有申请中使用pd我都有以下糖

// instantiate or initialize
var p = Proto.new();
// or without bolting onto Object.prototype
var p = pd.new(Proto);

但是我觉得强迫用户使用pd是不可取的,所以我不确定什么是使我的库可用的最佳方法。

  1. 人们创建Proto的新实例并致电.constructor他们自己
  2. 强制人们使用pd
  3. 提供.create样式工厂功能
  4. 放弃并使用new <Function>.prototype
  5. 已经提到过1和2。

    3基本上是

    Proto.create = pd.new.bind(pd, Proto);
    
    4会让我感到难过,但确认一种已知的标准做事方式会增加可用性。

    通常在使用非标准OO模式时,允许人们在其应用程序中使用我的库的最简单机制是什么?

    我现在很想说

    // here is my Prototype
    Proto;
    // here is how you instantiate a new instance
    var p = Object.create(Proto);
    // here is how you initialize it
    // yes instantiation and initialization are seperate and should be.
    p.constructor();
    // Want sugar, use pd.new
    

2 个答案:

答案 0 :(得分:1)

现在,如果您使用一个小API来帮助您构建传统的构造函数,那么您可能会在库客户端上最简单,使用看起来几乎像prototypes-as-classes的语法。 API使用示例:

// Superclass
var Person = Class.extend({
    constructor: function (name) {
        this.name = name;
    },
    describe: function() {
        return "Person called "+this.name;
    }
});

// Subclass
var Worker = Person.extend({
    constructor: function (name, title) {
        Worker.super.constructor.call(this, name);
        this.title = title;
    },
    describe: function () {
        return Worker.super.describe.call(this)+" ("+this.title+")";
    }
});
var jane = new Worker("Jane", "CTO");

实现:

答案 1 :(得分:0)

我认为可行的方法是根据“use pd”选项提供new(Prototype, [arguments])功能。从依赖的角度来看,它甚至应该不那么糟糕(因为无论如何你可以单独打包这个函数,并且只有几行代码)

提供特殊功能也符合某种历史观点。如果你回到Smalltalk,或者甚至在像Python这样的最近的情况下你有对象创建(新)和初始化(init,构造函数)的单独函数,唯一的原因是我们没有注意到分离是因为它们提供了句法用于对象实例化的糖。