Pull to refresh
11

Программист

3
Subscribers
Send message

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


ну причем здесь виджеты

Виджеты здесь при том, что речь идет о состоянии виджета.


К сожалению вместо конструктивного обсуждения Вы опять скатились на раздраженно-снисходительный тон, который считаю неуместным в подобных обсуждениях. Уверяю Вас, что у меня достаточный опыт разработки, чтобы суметь обосновать сказанное в статье. Но с Вашей стороны я не вижу потребности это понять, а у меня нет никакого желания общаться в таком тоне. Поэтому со своей стороны я заканчиваю эту дискуссию. Пусть каждый остается при своем мнении.

На счет киллера и биатлониста Вы абсолютно правы: они оба стреляют. И то, что они стреляют является существенным свойством обоих. Поэтому, если бы мне нужно было реализовывать это, то я бы воспользовался наследованием или реализацией интерфейсов (в зависимости от потребностей):


abstract class Shooter {
  void shoot();
}

class Killer extends Shooter {}

class Biathlonist extends Shooter {}

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


Также не нужно путать важное свойство и существенное свойство. Свойство может быть важным, но не существенным. В частности в приведенном Вами примере с SingleTickerProviderStateMixin. Этот mixin безусловно добавляет важное свойство к виджету, но не существенное, так как при наличии или отсутствии этого свойства виджет остается виджетом. А вот если у виджета убрать или добавить существенное свойство, то он либо перестанет быть виджетом вообще, либо станет принципиально другим виджетом (примером принципиально разных виджетов являются StatelessWidget и StatefulWidget)


Поэтому приведенный мной кейс работает и в данном случае. И к нему следует относится не как к единственному частному случаю, а как к некоторому обобщению, в рамки которого укладываются все варианты использования примесей (ну или почти все).

Моя цель была не в том, чтобы разобрать тысячи вариантов использования примесей. Серди этих тысяч есть и хорошие и плохие. Моя задача была показать, в каких случаях использование примесей дает преимущество перед наследованием и интерфейсами. А если мы говорим о критике, то я рад критике, но критика бывает разной: конструктивной и деструктивной. При конструктивной критике, когда говорят, что есть ошибка, то показывают, в чем она. При деструктивной — просто говорят, что все не правильно без всяких пояснений. Вы сказали, что описанные мной варианты применения примесей ошибочны, но не показали, в чем именно эта ошибка. И тон Вашего обращения агрессивен, потому и был сделан вывод, что Вы обиделись на то, что Ваш пример был подвергнут критике (замечу, что конструктивной, так как было указано, что в этом примере не так). Если у Вас есть конструктивные замечания, то я готов их услышать. Если же их нет, то лучше закончить эту дискуссию.

Прошу прощения, если я Вас обидел

В Dart есть экстеншены:


extension SuperInt on int {
  List<int> to(int end) => List.generate(end - this + 1, (i) => this + i);
}

После этого можно делать так:


final range = 2.to(5); // range = [2, 3, 4, 5]
К сожалению в node.js это не всегда так. Если обработчика не будет, то скрипт завершится без ошибок, даже если они на самом деле есть.

Information

Rating
Does not participate
Location
Петрозаводск, Карелия, Россия
Date of birth
Registered
Activity