2012-11-08 9 views
5

że chcę utworzyć następujący API:Wykorzystaj nowe słowo kluczowe opcjonalnie

var api = function(){} 

api.prototype = { 
    constructor: api, 
    method: function() { 
    return this; 
    } 
}; 

Teraz to będzie działać jak:

var myApi = new api(); 
myApi.method(); 

Ale powiedzmy, że chcę, aby słowo kluczowe new opcjonalne, tak, że będzie to działać:

api().method(); 

bym z mojej głowy robić:

var api = function() { 
    if (!(this instanceof api)) { 
    return new api(); 
    } 
}; 

Ale zastanawiałem się, czy można to w jakiś sposób zarażać, czy też istnieją inne niebezpieczeństwa związane z używaniem tej metody? Wiem, że f. Ex jQuery tego nie robi (odciążają konstruktora do metody prototypowej), więc jestem pewien, że istnieje dobry powód, aby tego nie robić. Po prostu ich nie znam.

+1

Twoje rozwiązanie wygląda doskonale, widziałem, że jest używane w wielu miejscach. Zobacz [tutaj] (http://ejohn.org/blog/simple-class-instantiation/), na przykład. – bfavaretto

Odpowiedz

2

zwraca obiekt w funkcji konstruktora.

function Car(){ 
    var obj = Object.create(Car.prototype); 
    obj.prop = 1; 
    return obj; 
} 
Car.prototype = { 
    method: function(){ } 
}; 

//test 
var car1 = Car(); 
var car2 = new Car(); 
+0

'Object.create (...)' jest szczególnie dobre, ponieważ używa przymusu do przesłuchania i eliminuje wszelkie odniesienia do 'this' w konstruktorze, więc nie musisz rozumować o tym, co' this' jest w kontekście konstruktora . Metody będą nadal miały dostęp do "tego" zgodnie z oczekiwaniami. – Eric

-1

Wybierz jedną lub drugą konwencję. Jeśli chcesz używać obiektów do obsługi uchwytów API, ale nie chcesz, aby ludzie używali new, użyj dwóch funkcji. Api(), który jest konstruktorem dla obiektów, i api(), która jest zwykłą funkcją, która po prostu zwraca nową instancję Api.

Nie sądzę, że istnieje jakieś zagrożenie dla tego, co proponujesz, to po prostu wydaje się bez sensu i nie podoba mi się pomysł funkcji, która wykonuje dwie rzeczy naraz.

+1

Dodanie opcji "nowy" opcjonalnie pozwala zespołom korzystać z interfejsu API w sposób zgodny z ich własnymi konwencjami. Niektóre zespoły są zdecydowanie przeciwko "nowym" z powodu swoich gier, a inne używają go w podobny sposób do języków z dziedziczeniem. Byłoby miło, gdyby API nie zmusiło drużyn do łamania konwencji w ten sposób. Klasa 'Router' Express.js jest dobrym przykładem opcjonalnego' nowego'. – Eric