Миксины для “классов” в JavaScript

[k12th]

Если миксин тупой и является просто набором методов, которые вы просто дергаете сами вручную, то можно даже не городить огород, а тупо вынести их в отдельный модуль и точно так же дергать в нужном контексте.

А если миксину нужна инициализация или еще какое-то участие в жизненном цикле объекта, в который мы его вмикшиваем, да еще если они наследуются друг от друга, то получаем, по факту, все прелести и проблемы множественного наследования. Чтобы этого избежать, лучше взять компоненты.

[friday]

А зачем делать из миксинов цепочку? Чем плохо, например, смешивание всех миксинов в один промежуточный «класс» или вообще подмешивание их напрямую в прототип? Результат почти тот же (да, придётся пробежаться циклом, но это нужно сделать только один раз при инициализации), но цепочка прототипов будет короче, что влияет на скорость поиска и вызова методов.

[asavin]

Не всегда возможно смешать все миксины в один класс или напрямую в прототип. Например, если в цепочке А — миксин Х — миксин У — Б в миксине У доопределяется метод из миксина Х.
Ну и не стоит сильно переживать за длину цепочки, в реальных приложениях тормозить будут совсем другие вещи.

[Ilusha]

Цепочка миксинов это жесть.
Понятно, что такое решение появилось не просто так, но все же.

Начал использовать react.js с fluxxor, где нет классического наследования.
За пару месяцев втянулся, но миксины меня, порой, добивают.

Основные проблемы/неудобства, навскидку:

• поиск незнакомого миксина и разбор его работы;
• ide часто не понимает, что метод берется из миксина;
• говнокод, который писался под @todo исправить это позже
• часто миксины берут на себя большую функциональность, чем должны: по сути нужно уже выделять в отдельный класс, но это ведет уже к рефакторингу и очередной попоболи.

Понятно, что при грамотном подходе можно все решить, но, на мой взгляд, миксины усложняют код.
Инструмент интересный, в некоторых случаях — необходимый, но стоит к нему относиться осторожно.
Слишком уж легко выстрелить себе в ногу.