>> и злоупотреблении доминирующим положением на рынке iOS-устройств

Это самая смешная часть. Ещеб сказали "на рынке Apple устройств"

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

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

Итог: иногда приходится делать корявые штуки из-за поставленных задач. И спрос на хитрости в таких случаях есть.

Код — это текстовое представление программы.

Программа должна выполнять поставленные задачи с указанными параметрами эффективности.

Код имеет другую задачу: сохранение мысли программиста. Над большим проектом работают много программистов, самых разных. И код — это общий форум, это общение программистов друг с другом.

Если программа пишется один раз одним программистом — на качество кода можно и забить.

Так же понятна ситуация, когда пишутся прям очень оптимизированный код. Оптимизированный алгоритм, как бы он аккуратно не был записан, тоже сам по себе не будет являться обязательно легко понятным.

Но вообще я хз как и зачем писать код нечитабельно, если умеешь читабельно. Это как повар себе будет готовить собачий корм, ну типа для себя же.

а почему это проргаммисты идиоты? Может, все-таки продаки-менеджер идиот? или отдел качества? Или заказчик?

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

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

Я думал, это влияет только на объем общего кода, а не на скорость. Разве что на скорость сборки влияет.

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

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

И я не помню рекомендаций в "чистом коде", где бы советовали каждый чих превращать в миллион классов, тем более использовать наследование.

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

Динамическая типизация разрешалась в первом Dart по причине того, что так проще перейти на Dart с JS, а это виделась как большая аудитория.

Во второй версии строгая типизация пришла потому, что так хотели пользователи языка.

Так язык и развивается дальше, учитывая пожелания тех, кто его использует. И мне так очень даже нравится.

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

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

Например, количество предмета, патронов. Можно описать поле countable, которое является union типом. Может выглядеть так:

class ItemModel {
  final Countable countable;
  final ItemType itemType;
  ItemModel({this.type, this.countable});
  //...
}

final ammo50 = new ItemModel(
  type: ItemType.ammo50, 
  countable: Countable.many(137),
);

final int count = ammo50.countable.when(
  single: () => return 1,
  many: (count) => return count
);

Этот union type штука удобная, из функционального программирования пришла. Отличная вещь!

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

Например, патроны не просто в количестве 137 штук, а они в инвентаре должны отображаться пачками по 50. Тогда Countable может предусматривать третий вариант stacked с дополнительным полем stackMax = 50.

Удобно, потому что свойством "количество" могут обладать предметы из разных категорий. Не нужно будет делать сложные наследования, миксины. А самое главное, не нужно будет делать проверки на тип предмета.

Еще с наследованием проблема в том, что когда мы делаем проверки на тип, мы должны знать, какой список классов и интерфейсов проверяем. А если его надо обновить из-за того, что мы изменили структуру дерева наследования? А если таких мест в коде много, и их еще поискать надо все, чтобы не забыть?

Предмет это абстрактный класс или же интерфейс? Так как это объект с данными, а не объект поведения - это абстрактный класс.

Не могу согласиться. Предмет в инвентаре — это модель, ни больше, ни меньше. Совсем не обязательно использовать абстрактные классы и наследование для разделения объектов по общим значениям в модели. Я, например, в моделях никогда вообще не использую наследование, методы, абстракции.

Вот ниже пример, как предметы героя описываются простым классом. Теги — лишь как один из способов хранить дополнительные особенности каждого предмета.

itemType поле описывает основную разницу между предметами. По типу легко определить, что с этим предметом можно делать. Но можно вообще на одних только тегах все описать. Set — это лист, массив, в котором не могут повторяться одинаковые значения, а порядок не важен.

@immutable
class ItemModel {
  final String id;
  final ItemType itemType;
  final Set<Tag> tags;
}

Ну предположим у нас в инвентаре есть шмот перса, а есть расходники. Это объект одного класса? Если да, то почему и зачем? 

Да, у них одинаковое поведение. Они просто лежат в кармане героя, пока их не достанут. У них разный тип, но тип совсем не обязательно указывать через класс. Можно взять enum.

На клике что происходит, кто определяет и как. расходник не является предметом или шмотка не является предметом.

"Пользователей" предмета полно. Это может быть окно крафта, окно продажи, окно экипировки героя. И везде будут разные функции на "клик" или "drag-n-drop". Вот тот, кто вызывает из памяти список предметов, тот и говорит, что он хочет делать с предметами.

Класс модели совсем не должен содержать поведения, только описание предмета. Поведение делает бизнес-логика.

Скорее всего это просто функция, которая по описанию предмета и определяет, как с ним сделать что-то: какие возможные действия предложить, какую цену на продажу выставить, на какую часть тела это можно одеть. На каждую задачу своя функция, своя логика.

Например, вот способ подсчета стоимости предмета:

double getItemPrice(ItemType type, Set tags) {
  late double price;
  switch (type) {
    case ItemType.sword01:
      price = 12.0;
  }

  if (tags.contans(Tag.broken)) price = price * 0.1;
  if (tags.contains(Tag.rare)) price = price * 10;
}

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

Я понимаю, что можно и через ООП и наследование все описать, или еще какими-нибудь другими способами, двумерными массивами, например, вообще без каких-либо классов. Тут нет явно правильного и неправильного варианта. Просто у каждого подхода будут свои особенности.

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

А что наследование дает взамен здесь? Я не знаю. Но чем меньше модель знает о вариантах поведения, тем лучше. Чем меньше связанности в коде — тем лучше. Чем гибче код — тем проще его изменять, это хорошо.

Я щас подумал, что в старых играх я видел мешочки: такой элемент в инвентаре, куда предметы можно засовывать. То есть это предмет с предметами.

В таком случае можно использовать наследование для разделения простой ячейки с предметом и ячейки-контейнера с кучкой предметов. Но можно и не через наследование это сделать.

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

• Почему абстрактный класс BaseItem без ключевого слово abstract? Зачем вообще строить какую-то невнятную иерархию наследования без обозначения, кто его наследники? Какая вообще проблема решается через наследование? Почему просто не создать структуру только для чтения под названием InventoryCell (BaseItem - слишком абстрактное название)?

Стандартный подход в геймдеве. Да это может быть класс контейнер в дальнейшем компонентном подходе. Это классика, это при разработке 5-6 взрослых игр знать надо

Я поддержу второго комментатора. Чтобы применять наследование, нужна весомая причина. Данные в инвентаре — это модели, у них я бы не стал делать разное поведение, или какое-то поведение в принципе.

Но ваша аргументация в духе "все так делают, это знать надо" оставляет меня желать лучшего.

Но я радуюсь, когда в моделях предлагают не хранить графику и локализацию. Разделение — это хорошо.

А можно ссылок? Я не нашел

Что-то я так и не понял, как по IT компаниям "ударила" пандемия. Что поменялось, но что обязательно в худшую сторону в подавляющем количестве направлений, параметрах — я не вынес из статьи.

А почему не рассматривали Notion? Мне кажется, он идеален, кроме offline режима. Но я надеюсь, его как-нибудь прикрутят