Справедливо будет сказать, что большинство разработчиков Javascript сталкивались с различными экземплярами объектов; функциональное, функционально-разделяемое, прототипическое и, конечно же, псевдоклассическое.
Есть отличное чтение, в котором описываются различия, но я хочу рассмотреть отношения между каждым типом. По большей части переход по этой цепочке имеет смысл и вполне логичен.
От функционального к функциональному разделяемому
Давайте попробуем сэкономить немного символов, места и времени. Вместо создания повторяющихся методов каждый раз при создании объекта давайте создадим ссылки на общие методы.
Когда я думаю о создании экземпляров с совместным функциональным доступом, я склоняюсь к тому, чтобы обращаться к каждому методу по одному, а не к расширению всего объекта методов. Больше всего потому, что я никогда не использовал функциональный общий доступ, где у меня было большое количество методов, которыми нужно было поделиться. Также я чувствую, что это помогает проиллюстрировать тенденцию к абстрактности вверх по цепочке инстанцирования.
От функционального до прототипа
Но, возможно, я не хочу отслеживать отдельные методы в своих функциях-конструкторах. Может быть, мои пальцы устают. Это кажется вполне разумным, если в вашем классе МНОГО методов.
Создание дополнительного объекта для общих методов имеет смысл. А еще лучше, давайте сделаем его прототипом, чтобы нам не нужно было обновлять отдельные объекты после их создания.
В то время как большинство людей назначают общие методы объекту-прототипу, мы можем просто избыточны, если у вас уже есть объект-прототип, который вы можете использовать. Более того, это приближает нас к псевдоклассике, поэтому, когда мы оцениваем этот прыжок, мы видим, насколько он на самом деле сумасшедший.
От прототипа к псевдоклассике
На мой взгляд, этот шаг в абстракции довольно сумасшедший. Особенно, если вы изучаете его в первый раз.
Во-первых, есть «новое» ключевое слово, с которым нужно иметь дело. Откуда это взялось?
Во-вторых, учат, что есть некоторые скрытые строки кода, которые автоматически запускаются с ключевым словом «новое». Это немного произвольно, особенно для языка без встроенной функции реверса строки.
var myString = “reversethis” // all these calls to reverse a string var revString = myString.split(“”).reverse().join(“”) // Ruby code // a = “abc” // reva = a.reverse
(На самом деле мне нравятся строгие требования Javascript, но я просто указываю на несоответствие.)
Наконец, почему «это» в функции-конструкторе не относится к окну?
var logFunc = function() {
console.log(this);
}
// invoked logFunc, this is window. Logs window.
logFunc()
var consFunc = function() {
this.prop1 = “How now brown cow.”
}
// creats new object with above construct in the global scope
// this refers to itself, not window
var newObj = new consFunc;
Допустим, я создаю функцию, которая регистрирует «это» и вызывает ее в глобальной области видимости. Он правильно регистрирует окно. Но если у меня есть функция-конструктор и я использую наше ключевое слово «new» перед вызовом конструктора, «this» внезапно относится к чему-то, что не является окном.
Как вы примиритесь с этим? Один из способов — думать о ключевом слове «новый» как о вызове в контексте самого себя объекта, который нужно создать. (Так экзистенциально) Независимо от того, технически правильно это или нет, это помогает мне понять то, что я вижу как не очень логичный шаг вверх по цепочке инстанцирования объектов.
