Pull to refresh

Comments 4

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

А если миксину нужна инициализация или еще какое-то участие в жизненном цикле объекта, в который мы его вмикшиваем, да еще если они наследуются друг от друга, то получаем, по факту, все прелести и проблемы множественного наследования. Чтобы этого избежать, лучше взять компоненты.
А зачем делать из миксинов цепочку? Чем плохо, например, смешивание всех миксинов в один промежуточный «класс» или вообще подмешивание их напрямую в прототип? Результат почти тот же (да, придётся пробежаться циклом, но это нужно сделать только один раз при инициализации), но цепочка прототипов будет короче, что влияет на скорость поиска и вызова методов.
Не всегда возможно смешать все миксины в один класс или напрямую в прототип. Например, если в цепочке А — миксин Х — миксин У — Б в миксине У доопределяется метод из миксина Х.
Ну и не стоит сильно переживать за длину цепочки, в реальных приложениях тормозить будут совсем другие вещи.
Цепочка миксинов это жесть.
Понятно, что такое решение появилось не просто так, но все же.

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

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


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

Articles