obchodzenia konstrukcja API i OO cukier

Question

czytanie wprowadzający:

• Prototypes as "classes"
• OO JS

Po wzorców opisanych powyżej tworzę Biblioteka/API w następującym

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

Teraz aby użytkownicy bibliotek mogli wchodzić w interakcje z moimi prototypami (które nie mają ply funkcje fabrycznych) mają do instancji i zainicjować obiektu

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

To jest nieprzyjazny i rozwlekły sposób zmuszając użytkowników do instancji i zainicjować swoje obiekty.

osobiście ponieważ używam pd we wszystkich moich zastosowań Mam następujący cukier

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

Jednak myślę, że to niedobry zmusić pd na użytkowników, więc nie jestem pewien, co jest najlepszym sposobem, aby moje biblioteki użytkowej .

1. Ludzie tworzenia nowych wystąpień Proto i nazywają .constructor samym sobą
2. zmusić ludzi do korzystania pd
3. Daj FUNKCJE fabrycznych .create styl
4. zrezygnować i korzystać new <Function> i .prototype

1 i 2 zostały już wymienione.

3 będzie zasadniczo

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

4 pozwoliłoby mi smutno, ale potwierdzający do znanej standardowy sposób robienia rzeczy zwiększa użyteczność.

Generalnie przy korzystaniu z niestandardowych wzorów OO, jakie są najprostsze mechanizmy umożliwiające użytkownikom korzystanie z mojej biblioteki w aplikacji?

Jestem obecnie chciałoby się powiedzieć

// 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 

Answer 1

Na razie najprawdopodobniej najprościej będzie na swoich klientach bibliotecznych, jeśli użyjesz małego API, które pomoże ci zbudować tradycyjną funkcję konstruktora, używając składni, która wygląda prawie jak prototypy-klasy. Przykład użycia 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"); 

Wdrożenia:

• http://ejohn.org/blog/simple-javascript-inheritance/
• mam przepisany Resig API, w sposób, który jest być może łatwiej zrozumieć: https://github.com/rauschma/class-js

Answer 2

myślę, że droga jest realizowanie funkcji new(Prototype, [arguments]) jak na opcję „Użyj pd”. Nie powinno to być nawet takie złe z punktu widzenia zależności (ponieważ i tak można spakować tę funkcję osobno i ma tylko kilka linii kodu)

Oferuje specjalną funkcję, która pasuje również do historycznej perspektywy . Jeśli wrócisz do Smalltalk lub nawet w nowszych przypadkach, takich jak Python, masz oddzielne funkcje do tworzenia obiektów (nowe) i inicjalizacji (init, the constructor) i jedynym powodem, dla którego nie zauważamy rozdzielenia, jest to, że zapewniają syntaktyczne cukier do tworzenia obiektów.