Вы меня совершенно не обидели. Вы не правильно поняли мой комментарий, судя по всему. Хотелось хотя бы более глубокого погружения в тему, раз уж вы решили восполнить пробелы информации в данной теме (хотя с этим я совершенно не согласен, информации более чем достаточно). А что на выходе — вы разбираете чужой пример выдернутый из контекста, потом приводите свой пример на основе которого делаете совсем не полный вывод, я бы даже сказал ошибочный, подавая его как правильный юзкейс. Самое правильное что вы написали, так это последний абзац. Вариантов использования в различных ситуациях можно придумывать до бесконечности. А учитывая, что вы хотели дать ответ на вопрос, когда же лучше использовать данный механизм, гораздо полезнее было бы уж тогда хотя бы рассмотреть кучу разных кейсов, при том рассмотреть их подробно. А в итоге статья получается не выполняет даже ту цель, которую вы поставили перед ней сами вначале. Удачи вам в последующих статьях, надеюсь вы здраво воспримете мою критику.
Серьезно? Вы пол статьи тратите на размышления по поводу логичности абстрактного примера из чужой статьи? На примеры стоит смотреть через призму того что они пытаются продемонстрировать, а не того, как можно было бы сделать это иначе. У примера с животными была конкретная цель — показать выгоду по сравнению с DDD. У примера с спортсменами, как раз то к чему вы пытались прийти. Для вынесения общего функционала, который может потребоваться в разных местах. В том числе и в ситуациях когда нет общего наследника, так и в ситуациях когда он есть. Как в ситуациях, когда это важное свойство, так и в ситуациях когда оно незначительно. Так что вывод «зачем вообще нужны mixin'ы» можно сделать как из моей статьи, так и из кучи англоязычных в сети, странно что у вас это не получилось.
К слову, вы пытались привести пример из флаттера, так вот в самом движке есть намного более яркий пример SingleTickerProviderStateMixin. Он как раз выносит важный функционал для воспроизведения анимаций в отдельный миксин, хотя используется этот миксин классамм с общим родителем, там даже ограничение стоит — «on State». Так что, по-моему скромному мнению, чтобы восполнить пробел существующих статей, нужно было сначала изучить их поподробнее, ну и естественно посмотреть реальные кейсы, которыми сам Flutter более чем богат.
Да. На фирме, где я работаю вообще есть негласное правило, работающее даже для документации — если можно использовать русский термин, то лучше использовать его, за исключением полностью перешедших понятий. Да и сам я считаю так же, или было писать везде mixin или так же используемое понятие примесь. Мне последний вариант кажется даже более приемлемым, допустим человек вообще не имеет понятие о том, как они работают, увидев слово примесь подсознательно начинает понимать о чем идет речь, в случае mixin также, а вот увидев написание миксин получает дополнительное ограничение к восприятию.
Сходу не могу представить ситуацию, когда надо было бы запрещать использование примеси в любых классах
Допустим есть функционал какого-нибудь API, которое, как мы закладываем, может использоваться на уровне контроллеров или менеджеров, но не может быть в логике задач, тогда такое может пригодиться. Да я сейчас привел другую архитектуру совершенно, и в целом это абстрактный конь в вакууме, но это просто первый пришедший в голову пример.
Извиняюсь за редактирование ответа, нечайно отправил сразу после вставки цитаты.
К слову, вы пытались привести пример из флаттера, так вот в самом движке есть намного более яркий пример SingleTickerProviderStateMixin. Он как раз выносит важный функционал для воспроизведения анимаций в отдельный миксин, хотя используется этот миксин классамм с общим родителем, там даже ограничение стоит — «on State». Так что, по-моему скромному мнению, чтобы восполнить пробел существующих статей, нужно было сначала изучить их поподробнее, ну и естественно посмотреть реальные кейсы, которыми сам Flutter более чем богат.
Но ваш пример лучше иллюстрирует ситуацию с помощью кода, возможно мне стоило описать и этот случай при рассказе про ограничение с помощью on.
Допустим есть функционал какого-нибудь API, которое, как мы закладываем, может использоваться на уровне контроллеров или менеджеров, но не может быть в логике задач, тогда такое может пригодиться. Да я сейчас привел другую архитектуру совершенно, и в целом это абстрактный конь в вакууме, но это просто первый пришедший в голову пример.
Извиняюсь за редактирование ответа, нечайно отправил сразу после вставки цитаты.