Comments 22
UFO just landed and posted this here
В конце концов proto это всего лишь синтаксический сахар вокруг свойств constructor и prototype. При этом не слишком широко применяемый и вошедший в спецификацию сравнительно недавно в 2015 году. Мне кажется что для понимания что там за кадром в классах es7 было бы полезнее знать именно основу прототипного наследования которая была в es с самых первых версий
Так же, как с помощью функций можно организовать и функциональную и процедурную парадигмы, так и с помощью прототипов можно организовать и практически класический ООП и тот кошмар который приведен в статье.
То что можно на лету менять прототип и его содержимое, тем самым меняя поведение конечной сущности, — это заслуга отнюдь не прототипного наследования (хотя косвенно и оно участвует), а динамической основы языка. Такое же поведение можно реализовать и без прототипов, если задаться целью.
Грубо говоря, наличие прототипов и динамичности позволяет как «вить веревки», так и «стрелять себе в ногу». Все зависит от желания пользоваться парадигмами или возможностями.
То что можно на лету менять прототип и его содержимое, тем самым меняя поведение конечной сущности, — это заслуга отнюдь не прототипного наследования (хотя косвенно и оно участвует), а динамической основы языка. Такое же поведение можно реализовать и без прототипов, если задаться целью.
Грубо говоря, наличие прототипов и динамичности позволяет как «вить веревки», так и «стрелять себе в ногу». Все зависит от желания пользоваться парадигмами или возможностями.
Именно об этом данная статья!
Как-то из статьи я этого не понял. Более того, понял что мысль донесена не правильно и об этом мой коментарий.
Почему мысль донесена не правильно?
Вы сравниваете классы и прототипы — вещи несравниваемые. Класс это сущность парадигмы ООП. Прототип — имплементация. ООП в JS ничем (за исключением нюансов) не отличается от ООП в других языках. JS имплементирует ООП с помощью прототипов, С++ компилятором со статическими сущностями. Обусловлено это тем, что первый — динамический интерпретатор, а второй статический компилятор (или проще: так получилось).
А все эти способности на лету чего-то портить никак не связаны ни с ООП ни с прототипами. Все это динамичность языка.
А вы пытаетесь показать разницу между классами и прототипами в том что прототипы можно менять или клеить на лету.
В этом и есть ошибка подхода.
А еще, наличие обьектов не делает ваш код обьектно-ориентированным.
А все эти способности на лету чего-то портить никак не связаны ни с ООП ни с прототипами. Все это динамичность языка.
А вы пытаетесь показать разницу между классами и прототипами в том что прототипы можно менять или клеить на лету.
В этом и есть ошибка подхода.
А еще, наличие обьектов не делает ваш код обьектно-ориентированным.
Вы хоть в Java коде
напишите, а то tom-то так и не создался
new Person()напишите, а то tom-то так и не создался
сущность достаточно широкое понятие и применяется в разных концепциях, уместее использовать понятие экземпляра
Как по мне, для джунов написано слишком академическим языком, из-за чего сложнее понять. Например эта статья воспринимается легче. Удивительно, но за 10 лет она практически не потеряла актуальность.
Почитаю! Извините если тяжело написано, я просто пытался передать свой опыт работы с начинающим разработчиками.
Не страшно, сама статья неплохая. Я сам пишу так-же, потом перечитываю и упрощаю. Разбиваю длинные предложения на простые, убираю лишние обороты, смотрю чтобы термины не плавали. Можно сказать, рефакторю текст. Примеры того что бросается в глаза:
- “сущности”, “инстанции”
“экземпляры” привычнее, иногда допустимо разговорное “инстанс” - “создавая отношение генерализации — специализации”
смотрится уместнее в статьях про нюансы ООП, UML. Здесь лучше “наследуя его” - “генерального класса(суперкласса)”
≈ “родителя” - “Класс представляет собой некий формализованный обобщённый набор характеристик сущностей, которые он может породить.”
тяжеловато, описание полегче
Это все конечно субъективно, может другие хабраюзеры не согласятся со мной.
Я употребил термин «сущность» для того чтобы показать, что это нечто физически конкретное… возможно не самая удачная идея.
Наследование это хороший оборот, но я сознательно употребил генерализации — специализации чтобы отразить суть происходящего. Ведь и в прототипной организации наследование. Но только в классовой организации присутствуют понятия подкласс и суперкласс.
Наследование это хороший оборот, но я сознательно употребил генерализации — специализации чтобы отразить суть происходящего. Ведь и в прототипной организации наследование. Но только в классовой организации присутствуют понятия подкласс и суперкласс.
Мне одному кажется странным данное утверждение
учитывая тот факт, что метод добавлен непосредственно в объект (в представленном коде), а не в его прототип, в этом поможет убедиться состав объекта на которое ссылается свойство __proto__
Соответсвенно и последующие рассуждения искажаются допущенным недопониманием рассматриваемого вопроса
//сущность tomSon давно уже создана, но мы добавляем свойства в её прототип и можем реализовать в ней поведение, которое будет оперировать этими свойствами
учитывая тот факт, что метод добавлен непосредственно в объект (в представленном коде), а не в его прототип, в этом поможет убедиться состав объекта на которое ссылается свойство __proto__
Соответсвенно и последующие рассуждения искажаются допущенным недопониманием рассматриваемого вопроса
Весьма актуальная статья на мой взгляд, с учетом продолжающегося роста популярности JS и ES6 в частности. Буду ждать следующих статей на эту тему.
Вопрос к объекту про типы: кто ты? В классических ООП языках тип объекта определяется классом. Класс может наследовать тип от одного или более других классов, а так же реализовывать интерфейсы. Таким образом типов у объекта может быть несколько.
Вопрос про свойства обьекта: чей ты? Объект может содержать собственные свойства или делегировать другому объекту (предку), и так по цепочке.
Классические ООП языки реализуют обе схемы, прототипные только вторую. Поэтому типы всех объектов в js одинаковы — это object. Слово class из ES6 лишь синтаксический сахар, который ни чего не меняет в плане типизации.
Более наглядно, с картинками, это описано в статье про python. Если там исключить классы, оставив лишь одни метаклассы, то получится почти как в JavaScript
blog.ionelmc.ro/2015/02/09/understanding-python-metaclasses
С точки зрения теории ООП особой разницы нет, т.к. она даёт лишь поверхностные определения. На практике это приводит к тому, что в js возможности, связанные с системой типов и их проверками довольно ограничены, по сравнению с классическими ООП языками.
Вопрос про свойства обьекта: чей ты? Объект может содержать собственные свойства или делегировать другому объекту (предку), и так по цепочке.
Классические ООП языки реализуют обе схемы, прототипные только вторую. Поэтому типы всех объектов в js одинаковы — это object. Слово class из ES6 лишь синтаксический сахар, который ни чего не меняет в плане типизации.
Более наглядно, с картинками, это описано в статье про python. Если там исключить классы, оставив лишь одни метаклассы, то получится почти как в JavaScript
blog.ionelmc.ro/2015/02/09/understanding-python-metaclasses
С точки зрения теории ООП особой разницы нет, т.к. она даёт лишь поверхностные определения. На практике это приводит к тому, что в js возможности, связанные с системой типов и их проверками довольно ограничены, по сравнению с классическими ООП языками.
Sign up to leave a comment.
Взгляд со стороны EcmaScript на общую теорию ООП