2011-09-21 10 views
10

Podobne do, ale różne od this question. Poniższy kod pochodzi z JavaScript: The Definitive Guide. Zasadniczo definiuje metodę dziedziczenia, która odwołuje się do Object.create, jeśli istnieje, w przeciwnym razie robi zwykłe stare dziedzictwo JavaScript, używając konstruktorów i zamieniając prototypy wokół.Zaleta korzystania z Object.create

Moje pytanie brzmi, ponieważ obiekt Object.create nie istnieje na wiele popularnych przeglądarek IE, jaki jest sens nawet próbując go użyć? Z pewnością zaśmieca kod, a jeden z komentujących na poprzednim pytaniu wspomniał, że Object.create isn't too fast.

Jaka jest korzyść z próby dodania dodatkowego kodu, aby od czasu do czasu wykorzystać tę funkcję ECMA 5, która może być wolniejsza od "starej" metody?

function inherit(p) { 
    if (Object.create) // If Object.create() is defined... 
     return Object.create(p); // then just use it. 

    function f() {}; // Define a dummy constructor function. 
    f.prototype = p; // Set its prototype property to p. 
    return new f(); // Use f() to create an "heir" of p. 
} 

Odpowiedz

9

Różnica prędkości nie jest bardzo istotne, ponieważ z natury prawdopodobnie nie będzie tworzenie zbyt wielu przedmiotów (setki, a nawet tysiące nie jest to, co ja nazywam dużo), a jeśli jesteś i prędkość krytyczny problem, który prawdopodobnie nie będzie kodował w JS, a jeśli oba powyższe nie są prawdziwe, to jestem pewien, że w ciągu kilku wydań wszystkich popularnych silników JS różnica będzie nieznaczna (tak jest już w przypadku trochę).

W odpowiedzi na pytanie, powody są związane nie przyspieszy, ale ze względu na wzór projektowania od Object.create jest faworyzowany do starej metody (z powodów opisanych w tym i innych odpowiedzi). Pozwalają na prawidłowe wykorzystanie atrybutów właściwości ES5 (co powoduje, że obiekty są bardziej skalowalne, a tym samym bardziej skalowalne) i mogą pomóc w hierarchii dziedziczenia.

To zaawansowana inżynieria. Gdybyśmy przyjęli linię "dobrze, że nie jest ona wszędzie wdrażana, nie miejmy mokrych stóp", rzeczy poruszałyby się bardzo powoli. Wręcz przeciwnie, wczesna i ambitna adopcja pomaga branży postępować, pomaga decydentom biznesowym wspierać nowe technologie, pomaga programistom ulepszać i doskonalić nowe pomysły oraz ramy wsparcia. Jestem zwolennikiem wczesnego (ale ostrożnego i nadal zgodnego wstecz) przyjęcia, ponieważ doświadczenie pokazuje, że czekanie na wystarczającą liczbę osób, aby wesprzeć technologię, może sprawić, że czekanie będzie trwało zbyt długo. Niech IE6 będzie lekcją dla tych, którzy myślą inaczej.

+0

To naprawdę przydatna odpowiedź; Rozumiem, dlaczego tworzenie byłoby lepsze, ponieważ daje ci dużą kontrolę nad właściwościami w obiekcie, który został utworzony. Rozumiem, dlaczego chcesz powiedzieć 'var bob = Object.create (userB, {" id ": {wartość: 12, wyliczalna: false' i tak dalej, ale nie spowoduje to gwałtownego zawieszenia tego kodu w IE9 i poniżej "Czy takie kodowanie nie byłoby ograniczone do (cudownych) sytuacji, w których można kontrolować przeglądarkę, której używają użytkownicy? –

+0

Innymi słowy, w IE8 nie tylko będę musiał uzyskać moją nową dziedziczoną metodę za pomocą starego JS metoda zamiany prototypów wokół, ale będę również musiała zmienić obiekt, który jest przekazywany, aby służyć jako "potomny" obiekt, który dziedziczy po userB. Zamiast '{" id ": {wartość: 12, wyliczalna: false 'nie będę potrzebował' {"id": 12, "name": "bob" 'i tak dalej? –

+0

@AdamRackis, to prawda, kod taki jak-jest niezgodny wstecz, ale jestem pewien, że istnieje projekty, które próbują i usprawniają te rzeczy, a jeśli nie, to jest to dobry pomysł.Nie byłoby trudno zautomatyzować te zmiany. – davin

Powiązane problemy