JavaScript ООП, запутался?

Question

[thehighhomie]

Прочитал книгу "JavaScript для профессионалов: 2 издание", и совсем запутался. В этой книге был представлен единственный шаблон создания повторного использования кода, то есть ооп. вот пример этого шаблона https://jsfiddle.net/7zn5ccgq/ Автор писал что в свойство prototype вообще не нужно лезть. На сколько я знаю, когда начинал учить JavaScript, во всех документациях которые читал, в том числе и на learn.javascript.ru, описывают что обычно предпочтительнее ооп в прототипном стиле. А вот в каком стиле как я обычно пишу codepen.io/radum/pen/xICAB (это не мой код, просто для примера) А тут автор, который jQuery создал. То ли пока я учил JavaScript что то поменялось в этом плане, а я так учил что и не заметил, то ли создатель jquery с ума сошел, то ли я вообще ничего не пойму... Помогите пожалуйста.

Answer 1

[Сергей Протько]

шаблон создания повторного использования кода, то есть ооп

Вы запутались. ООП не про повторное использование кода, функции/процедуры больше за это отвечают. Объекты отвечают за сокрытие состояния.

Автор писал что в свойство prototype вообще не нужно лезть.

Изнутри инстанса объекта - да. Когда ты описываешь новый тип объектов и хочешь отнеследоваться - то надо указать прототип объекта.

То ли пока я учил JavaScript что то поменялось в этом плане

Чуть поменялось, вышел ES2015, еще в прошлом году. Теперь все чуть проще и работа с прототипами объектов при наследовании/определении новых объектов стала чуть более прозрачной и удобной. И про createObject/defineProperties можно помнить только что бы понимать как все работает.

Comments

[thehighhomie]

так а как теперь понять, для чего вообще нужно повторное использование кода, если это не заменя ооп на прототипах, и как и то и другое на практике тогда применяется, я вообще запутался, столько время убил на изучение, мало того что трудно дается, так еще и вообше не туда пошел походу

[Константин Китманов]

Ну вообще-то ООП создавалась в том числе с расчетом на повторное использование кода, типа отнаследовался и тебе зашибись. Реальность оказалась сложнее и наследованием нынче советуется не злоупотреблять, all aboard composition train (пока не изобрели новую блестящую абстракцию). А вот сокрытие состояния в JS получается плоховато, даже если юзать defineProperty и Symbol — все равно полностью спрятаться не получиться, да и хрен бы с ним. Вот объединять данные и поведение в одной сущности — с этим ООП в JS справляется, и слава богам.

[thehighhomie]

Константин Китманов: можете пожалуйста пример из практики привести, где используются прототипы, и где используется оздания повторного использования кода? чтобы я понимал куда дальше копать и что учить, английский у меня не на том уровне чтобы читать любые источники, так что буду в рунете искать

[Константин Китманов]

thehighhomie: повторное использование кода используется, чтобы не писать два раза одно и то же — это усложняет понимание кода потом и неминуемо ведет к багам. Если честно, мне это кажется настолько очевидным, что я даже не знаю, как объяснять новичку.
В зависимости от ситуции оно может быть сделано на уровне функций, классов или библиотек/модулей. Классы в JS устроены на основе прототипов. В ES5 это эмуляция, в ES2015 (aka ES2015) это нативная фича, но под капотом все равно прототипы.
Писать вам синтетический пример, показывающий важность повторного использования кода и как это делается в классах, простите, не буду.

[thehighhomie]

Константин Китманов: хорошо, спасибо

[Сергей Протько]

thehighhomie: нет, наследование это плюшка, создавалось все для сокрытия состояния и изменения оного посредствам обмена сообщениями.

Как вы верно подметили, наследование при несоблюдении LSP наносит больше вреда чем пользы, я практически отказался от него (только в случаях когда надо устранить дублирование прибегаю).

thehighhomie: DRY это важно, но ООП на прототипах или с использованием классов, это все детали, суть ООП от этого не меняется ни сколечки. В JS даже более православное ООП (поскольку многое украдено из smalltalk).

[Сергей Протько]

thehighhomie: недопостил. "Прототипы" - это как базовый объект. Когда вы создаете new Object() внутри происходит копирование объекта прототипа. Когда вы вызываете метод у объекта, и у него оный не находится, JS спускается по цепочке прототипов и ищет ее реализацию. Так работает наследование. Собственно вас вообще это не должно парить.

Константин Китманов: забыл сказать - для инкапсуляции в JS используются модули, и это намного надежнее кастылей вида private/protected. В es2015 можно использовать комбинацию из модулей и weakmap для хранения состояния, если вы уж сильно переживаете за то, что кто-то будет им пользоваться извне.

[thehighhomie]

Сергей Протько: а что такое lsp и dry?)

[Сергей Протько]

thehighhomie: Принцип подстановки барбары лисков и Don't repeat yourself. Последнее больше не о коде а о устранении дублирования в логике. И как бы реализация объектной модели не сильно влияет на то, как что делать.

[Константин Китманов]

Сергей Протько: я-то вообще не переживаю, а с остальным согласен, модули рулят.

Answer 2

[Aves]

Собственно, в примере и используется наследование на прототипах, в методе extend текущий объект устанавливается как прототип создаваемого. Фактически, действие этого метода идентично обычному действию оператора new и функции-конструктора, только там в качестве прототипа берется объект в свойстве prototype функции, а здесь объект, в контексте которого вызван метод.

Comments

[thehighhomie]

так а каким на практике пользоваться лучше?

[Aves]

thehighhomie: Лучше в каком отношении? Вообще, в качестве синтаксического сахара классов ES2015 достаточно.

[thehighhomie]

Aves: я имею ввиду, где применяют такой шаблон на практике https://jsfiddle.net/7zn5ccgq/ а где такой codepen.io/radum/pen/xICAB ?

[Aves]

thehighhomie: так и не понимаю, что является критерием "лучшести", и как эти два примера вообще связаны, или противоречат друг другу. Вопрос из категории "сколько пробелов должно быть в отступе". Оба примера правильные, применяют то, что больше нравится.

[thehighhomie]

Aves: просто я думал всегда что ооп на практике в основном делают функциях конструкторах, и это основной способ и евляющийся приоритетом в JS. А тут прочитал эту книгу, и оказывается сам гуру jQuery предложил создавать конструкторы в литералах объекта. Вот по этому я не могу сейчас что мне и где еще почитать, чтобы все встало на свои места. Почитал еще сегодня эту главу, но ничего нового не нашел, так как читал внимательно и с серьезностью, но не доходит почему-то(. Посмотрел исходник jQuery, там ооп реализовано как в учебнике у него)

[Aves]

thehighhomie: на том же learn.javascript.ru вроде рассмотрены функциональный стиль и прототипный с достоинствами и недостатками. Судя по всему, "создавать конструкторы в литералах объекта" - это просто немного иное стилевое оформление прототипного ооп.
А проще всего использовать вполне удобный синтаксис классов из ES6.

[thehighhomie]

Aves: спасибо) а можно русскоязычную документацию по синтаксису классов из ES6?

[Aves]

thehighhomie: поиск выдал frontender.info/es6-classes-final и тот же https://learn.javascript.ru/es-class
Кстати, хорошую статью вспомнил - dmitrysoshnikov.com/ecmascript/ru-chapter-7-2-oop-...

[thehighhomie]

Aves: спасибо большое)