All geek questions in one place

API Design Processing and OO Sugar

Introductory reading:

Following the patterns described above, I create libraries / APIs as follows

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

Now that library users interact with my prototypes (which do not provide a factory function), they must create and initialize an object

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

This is an unfriendly and verbose way to get users to create and initialize my objects.

personally, since I use pd in all my applications, I have the following sugar

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

However, I find it undesirable to force pd to be used by users, so I'm not sure if the best way is to make my libraries useful.

  • People create new .constructor instances and call the .constructor themselves
  • Force pd
  • Give .create style to factory function
  • Refuse and use new <Function> and .prototype

1 and 2 have already been mentioned.

3 will be basically

 Proto.create = pd.new.bind(pd, Proto);

4 would make me sad, but acknowledging a well-known standard way of doing things increases usability.

As a rule, when using non-standard OO templates, the simplest mechanisms allow users to use my library in their application?

I am currently tempted to say

 // 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
+6
source share
2 answers

At the moment, you are likely to do this the easiest on your library clients if you use a small API that helps you create a traditional design function using syntax that looks almost like prototype-like-classes. API usage example:

 // 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");

Implementations:

+1
source

I think the way to work is to provide the new(Prototype, [arguments]) function according to the "use pd" option. It also should not be so bad in terms of dependencies (since you could separately distribute this function separately and have only a couple of lines of code)

Offering a special feature also matches the historical perspective. If you go back to Smalltalk or even in later cases, such as Python, you have separate functions for creating objects (new) and initializing (init, constructor), and the only reason we don’t notice the separation is that that they provide syntactic sugar to create an object.

0
source

Source: https://habr.com/ru/post/899693/

More articles:


All Articles