Как использовать Mixins для каждого типа наследования?

Question

Как использовать Mixins для каждого типа наследования?

1

Недавно я видел концепцию Mixin в javascript в основном через статью Real Mixins с javascript-классами. И, как я понимаю, это способ сделать множественное наследование абстрактными классами и больше похож на композицию, чем наследование. Я также читаю о композиции концепции над наследованием, как в статье "Композиция над наследством". Я знаю, что дискуссия о наследовании и композиции может быть очень длинной, но я решил избежать наследования в максимально возможной степени (по крайней мере, на данный момент).

Поэтому я хотел бы использовать Mixins так сильно, как я могу, с ES6, и в большинстве примеров я вижу три класса в действии, например, class A extends MixinB(C). Что делать, если я хочу расширить только класс B? Будет ли я делать что-то вроде class A extends MixinB(Object)? Это может быть анти-шаблон, как указано в документации к Mozilla.

Обратите внимание, что я мог бы сделать прямое наследование, например, class A extends B, но, как этот B больше не является Mixin, и мне понадобится другое объявление B если я хотел бы использовать его как Mixin.

Jp_ 11 сен. 2017, в 00:18

Источник

0

«Наследование - это не всегда правильный образец», не означает «рожать эту новую вещь, которую вы узнали в каждом месте, где вы ранее использовали наследство».
Ry-♦ 10 сен. 2017, в 22:04
1

Остерегайтесь блоггеров JavaScript, которые неправильно сочетают композицию. reddit.com/r/programming/comments/5dxq6i/… . Миксины и множественное наследование - это одно и то же, но они не являются композицией.
Jeff M 14 сен. 2017, в 06:58
0

> Это может быть анти-паттерном, как говорится в документации Mozilla. | Документация MDN говорит об исправлении обезьяны, что действительно плохо, но исправление обезьяны не то, что делает class extends .
Jeff M 14 сен. 2017, в 06:59
0

@JeffM ... с вашим пользователем reddit link MoTTs_ ссылается на aggregation . Поэтому, когда в комментарии говорится, что Composition - это компоновка, наследование - это микширование , это следует исправить, чтобы компоновка - это агрегация, а «включение» может быть достигнуто как композицией, так и наследованием . Когда люди используют шаблоны Object.assign / Trait , Object.assign или class ... extends их, по крайней мере в JavaScript , всегда сочиняют; но наследование дополнительно обеспечивает / охватывает подтипы. Q Q OP затем изменится на «Как использовать Mixins для каждого типа композиции?»
Peter Seliger 14 сен. 2017, в 12:56
0

@PeterSeliger Состав и агрегация - это практически одно и то же. Они различаются только по собственности на содержащийся объект. И, тем не менее, мы предпочитаем различать миксин или черту, или наследование не меняет конкретных проблем, с которыми мы сталкиваемся. Object.assign , Object.assign все еще подвержен проблеме хрупкой базы, которая обычно ассоциируется с наследованием.
Jeff M 15 сен. 2017, в 17:48
0

Я вижу чрезмерное использование Inheritance, и это не очень хорошая вещь, поэтому разве «множественное наследование» / compositon, выполненное Mixin, не должно быть лучшим шаблоном для чрезмерного использования? TL; DR Ссылка на Reddit @JeffM хороша, потому что я действительно думал, что в видео все концепции были правильными, поэтому мне нужно пересмотреть некоторые концепции. Но моя основная мысль заключается в том, что я писал код, не задумываясь об архитектуре, и я видел, что не в состоянии наращивать функциональные возможности так легко, как следовало бы. Поэтому моя главная цель - написать код, который в основном соответствует принципу Open / Closed (а также другим принципам SOLID).
Jp_ 15 сен. 2017, в 18:40

Показать ещё 4 комментария

Теги:

javascript

class

design-patterns

inheritance

mixins

2 ответа

Ещё вопросы

«Наследование - это не всегда правильный образец», не означает «рожать эту новую вещь, которую вы узнали в каждом месте, где вы ранее использовали наследство».
Остерегайтесь блоггеров JavaScript, которые неправильно сочетают композицию. reddit.com/r/programming/comments/5dxq6i/… . Миксины и множественное наследование - это одно и то же, но они не являются композицией.
> Это может быть анти-паттерном, как говорится в документации Mozilla. | Документация MDN говорит об исправлении обезьяны, что действительно плохо, но исправление обезьяны не то, что делает class extends .
@JeffM ... с вашим пользователем reddit link MoTTs_ ссылается на aggregation . Поэтому, когда в комментарии говорится, что Composition - это компоновка, наследование - это микширование , это следует исправить, чтобы компоновка - это агрегация, а «включение» может быть достигнуто как композицией, так и наследованием . Когда люди используют шаблоны Object.assign / Trait , Object.assign или class ... extends их, по крайней мере в JavaScript , всегда сочиняют; но наследование дополнительно обеспечивает / охватывает подтипы. Q Q OP затем изменится на «Как использовать Mixins для каждого типа композиции?»
@PeterSeliger Состав и агрегация - это практически одно и то же. Они различаются только по собственности на содержащийся объект. И, тем не менее, мы предпочитаем различать миксин или черту, или наследование не меняет конкретных проблем, с которыми мы сталкиваемся. Object.assign , Object.assign все еще подвержен проблеме хрупкой базы, которая обычно ассоциируется с наследованием.
Я вижу чрезмерное использование Inheritance, и это не очень хорошая вещь, поэтому разве «множественное наследование» / compositon, выполненное Mixin, не должно быть лучшим шаблоном для чрезмерного использования? TL; DR Ссылка на Reddit @JeffM хороша, потому что я действительно думал, что в видео все концепции были правильными, поэтому мне нужно пересмотреть некоторые концепции. Но моя основная мысль заключается в том, что я писал код, не задумываясь об архитектуре, и я видел, что не в состоянии наращивать функциональные возможности так легко, как следовало бы. Поэтому моя главная цель - написать код, который в основном соответствует принципу Open / Closed (а также другим принципам SOLID).

ComDubh · Answer 1 · 2017-09-11T10-44-00.000Z

Мне не понравилось это!

Поэтому я хотел бы использовать Mixins столько, сколько могу

При необходимости используйте микшины, а не потому, что вы хотите их использовать. Наследование подходит для фиксированных, прочных отношений. Миксины полезны, когда у вас есть небольшая часть функциональности, которую вы хотите разделить с несколькими классами, которые не связаны друг с другом.

Пожалуйста, не думайте, что я пытаюсь сделать мой код хуже с Mixins, я говорю, что «я хотел бы использовать Mixins столько, сколько я могу» и под словом «могу» я имею в виду, так что здесь лучше использовать наследование? Использование Mixin было бы хакерским для неоправданного? Хорошо, я буду использовать наследование ". Ваш ответ больше похож на комментарий, так как вы не отвечаете на вопрос, который я задал.

lilezek · Answer 2 · 2017-09-10T20-29-00.000Z

Я думаю, что решение для того, что вы ищете, это изменить определение функций Mixin.

Вместо того, чтобы:

MixinB(WhateverClass)

Вы могли бы:

Mixin(MainClass, otherClass1, otherClass2...)

Где это было бы правдой:

MixinB(C) = Mixin(B, C)