TheShock
0
Создание всех фабрик? Похоже на «у моего класса Game одна ответственность — чтобы игра работала».

Меня всегда в Composition Root смущала перегруженность корня.
TheShock
0
Фабрика создается в Composition Root

Не многовато ли ответственности для Composition Root — создать по фабрике на каждую абилку и не только?
TheShock
0
А где возьмет их тот, кто создает фабрику?
TheShock
0
Если сейчас он таким не является, то в будущем — весьма вероятно, «если вдруг еще понадобится влиять на животных»

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

На самом деле в вашем коде недостатки в том, что юнит должен иметь описание каждой абилки. Т.К. юнит — это просто айдишник + совокупность всех абилок (если передвижение — тоже абилка), то значительно выгоднее логику абилки хранить в коде абилки и, соответсвенно методы а-ля activateStimPack — лишние. Представьте сколько методов в юните должно быть для сотен абилок?

Я тоже знаю, что мой подход не идеален. У меня логика абилок описывается в абилках (так как их очень много), а некоторые core-вещи даже дешевле описать в самих системах.

Вот допустим, у нас есть HitPointsSystem, у нее есть что-то вроде API, которое позволяет влиять на распределение демеджа, а абилки уже пользуются этим API. HitPointsSystem слегка разрастается, но зато абилки значительно сокращаются и поток кода становится значительно более явным.
TheShock
0
Рабочее название, обычно, дается при старте разработки.
TheShock
+1
Давайте с псевдокодом.
TheShock
0
AwesomeAbility в моем примере далека до God-object, хотя она и правда имеет многовато обязаностей. Но слишком много обязаностей не всегда означатает God-object. Божественный объект — это что-то вроде класса GameController, где описаны и создание цветов и все абилки и так далее.

Декомпозировать можно по разному, в том числе полегче:
class AwesomeAbility extends ComplexAbility {

  public Ability[] CreateParts () {
    return {
      new CrewSubAbility(),
      new PlantsSubAbility(),
      // ...
    };
  }
  
}


Но мы ведь говорим сейчас не так о декомпозиции, как о работе с зависимостями. У вас вручную создаются громоздкие конструкторы в вашем классе. И непонятно, кто именно будет создавать все эти листенеры и в них передавать зависимости. Так же непонятно, где именно вы хотите хранить стейт для абилки, если у вас она столь разбита. Например, если отключение абилки завязано на время или какой-то тригер. Скажем, абилка работает три дня, или пока не нажмут рычаг. А если абилка может навешиваться несколько раз? Ну классическая баф эффект с рандомным значением (помните, как в СтарКрафте маринерам много раз нажимали шприц, чтобы повысить статы?):

Вот представьте, вы юнитам добавляете
unit.AddAbility( new AttackIncrease(Random(3, 10), Seconds(Random(10, 20))) )
unit.AddAbility( new AttackIncrease(Random(3, 10), Seconds(Random(10, 20))) )
unit.AddAbility( new AttackIncrease(Random(3, 10), Seconds(Random(10, 20))) )


И вот, через разное время должна слететь одна, потом вторая, потом третья абилка.

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

{
  unitId: 123,
  effects: [
    { ability: "AwesomeAbility", timeLeft: 24, power: 12 },
    { ability: "AwesomeAbility", timeLeft: 14, power: 7  },
    { ability: "AwesomeAbility", timeLeft: 28, power: 29 },
  ]
}


Ну то есть я не отрицаю декомпозицию, но материнский объект должен оставаться доступным.

Кстати, иногда абилки могут складываться из других абилок, которые могут работать сами по себе. Скажем, абилка «Увеличьте атаку на 2 за счет уменьшения прочности в два раза» может складываться из двух уже существующих абилок «Увеличение атаки на Х» и «Уменьшение прочности в Х раз», тут тоже удобен подход с ComplexAbility
TheShock
0
Я не совсем понял, как вы предлагаете создавать эту комплексную абилку? Вместо того, чтобы создать одну AwesomeAbility — создать 5 подабилок? А что это даст?
TheShock
+1
В пятом Думе запустить третий, в котором запущен первый
TheShock
+3
Ваша фабрика со статикой, по сути, тот же синглтон разделенный на два класса. Да, я понимаю, что он перестает нарушать принцип «S», но смысл? Все остальные недостатки остаются.

$result = Database::query( $query );

А тут вообще пошла процедурщина, пусть и на классах.

В вашем Service Locator просто отвратительно использование строк, да и статическая типизация отваливается напрочь. В C#, конечно, можно было бы сделать это красиво благодаря Дженерикам. Что-то вроде такого:

var conn = services.Get<IDatabaseConnection>();
conn.query()


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

Внедрение зависимостей — уже ближе к хорошей альтернативе, чем к плохой альтернативе, но непонятно, что делать в сложных приложениях с сильными зависимостями (в бизнес-логике). Вот представьте игрушку, вроде RimWorld. Активируешь какую-то абилку, а она одна влияет на настроение всех жителей мужского пола, на рост растений, а также на вероятность заспаунится металлических жуков, если прошло больше 3 лет с начала игры и на складе лежит не меньше, чем 1000 единиц металла и сложность игры на ниже «легкой». Как должен выглядеть конструктор такой абилки?

class AwesomeAbility extends Ability {
  
  public CrewContainer crew;
  public PlantsManager plants;
  public EnemySpawner spawner;
  public GameTime time;
  public PlayerStorage storage;
  public GameConfig config;
  
  public AwesomeAbility (CrewContainer crew, PlantsManager plants, EnemySpawner spawner, GameTime time, PlayerStorage storage, GameConfig config) {
    this.crew = crew;
    this.plants = plants;
    this.spawner = spawner;
    this.time = time;
    this.storage = storage;
    this.config = config;
  }
}


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

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

class AwesomeAbility extends Ability {
  
  public CrewContainer crew;
  public PlantsManager plants;
  public EnemySpawner spawner;
  public GameTime time;
  public PlayerStorage storage;
  public GameConfig config;
  
  public AwesomeAbility (Game game) {
    this.crew = game.crew;
    this.plants = game.objects.plants;
    this.spawner = game.enemy.spawner;
    this.time = game.time;
    this.storage = game.player.storage;
    this.config = game.config;
  }
}


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

У меня есть еще классические лампы накаливания, но я ими пользуюсь чуть чаще чем никогда:



Вы вцелом отрицаете LED-свет для домашнего использования?
TheShock
0
Интересно, дайте больше инфы. У вас только красный светодиод как источник света и при этом морс кажется белым?

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

Или вы имеете ввиду, что скатерть и морс — смотрятся одинакового цвета и потому морс кажется белым?
TheShock
0
Нет, конечно, только для красоты. Как основной у меня есть белая лента
TheShock
+2
Я не уважаю вас как личность, но это не помешало бы мне судить о весомых аргументах, если бы они у вас были.
TheShock
+2
Если бы мне было интересно ваше мнение, я бы не настаивал на аргументах.

Ваше мнение — не интересно, а аргументов все еще нету.
TheShock
+1
Я вашу глупость пропускаю, так что случай очевидно тот.
Аргументов пока, к сожалению, не было. Очевидно, у вас их нету.
TheShock
+1
Если кратко, то кроме перехода на личности аргументов у вас нету.

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

Четыре раза! Начинаю думать, что вы излишне зациклились на мне.

Еще раз повторюсь: есть аргументы — говорите их. Аргументы дать не можете — валите.
TheShock
+2
Хотелось бы услышать аргументы, в чем мои рассуждения — неправильные. Пока от вас лишь пустые слова. Например,

Квалиа — это «необычный термин для обозначения самой обычной из возможных для нас вещи: того, как вещи выглядят для нас»

интерпретациями мозга, которые вообще не о волнах

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

Вопрос — по какой причине глаз считает, что он красный. Найболее логичное объяснение — мандарин отражает «красные волны» (волны длиной 620-630 нм), не отражает зеленые и синие, а никакой другой свет на него не попадает.

Если у вас есть другое научное объяснение — пожалуйста, приведите его. Но без аргументов из разряда: «ваша гипотеза разрушает мою аргументацию, потому она мне не нравится».

И почему вы говорите, что в отраженном свете — иные пики? Откуда вы это взяли?
TheShock
+2
Вот вам пики, нагуглил их:
image

А еще у меня есть такой прекрасный прибор, называется «глаза». Я смотрю на мандарин (который при дневном освещение желто-оранжевый), а он при моем лед-освещении — красный как клубника!

Тут вступает в дело другой прибор — называется «мозг» и я строю элементарные логические цепочки на базе начальных знаний про физику света.

Мандарин кажется красным, значит он отражает красный свет светодиода и не отражает зеленый и синий.

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

Предположительная приблизительная отражательная способность мандарина:


Именно при таком графике отражения от будет казаться желто-оранжевым при дневном свете и ярко-красным при свете RGB-светодиодов
TheShock
0
Если кто-то лучше понимает почему это не так — расскажите плиз

Так, но не всегда. Если вы слушаете музыку и комплименты, то музыка не должна прорываться, чтобы отдать компилятору еще 1%, даже если он активен.


Грубо говоря — Есть какие-то дешевые 1% задачи, которым неплохо бы иметь повышенный приоритет

TheShock
+1
Вопрос только в том, какие датчики засвечивает ИК диапазон. Если он средне пропускается красным и зеленым фильтром и не пропускается синим, то без дополнительного ик фильтра будет выглядеть именно коричневым
TheShock
+3
Звучит как возражение, хотя по факту является подтверждением

Я уже приводил тут пример с желтым мандарином, который в белом rgb свете с тремя пинками кажется яркокрасным. Потому что он прекрасно отражает желтый, Хорошо отражает красный и совершенно не отражает зеленый.
TheShock
+1

Как можно объединять c++ и c#? Это ведь два совершенно разных языка! Как JavaScript и Java

TheShock
+3
В чём сила Redux?

Статьи про редакс для новичков — это как типичный неудачный форсед-мем. Всем уже тошно от одного заголовка, а они все лезут и лезут.
TheShock
+8
Очень аккуратно оформлено, но к сожаления не правильно. Неправильно с самого начала и до самого конца.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных статей, на том же Хабре.

Очень неаккуратный комментарий и, к сожалению, местами неправильный.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных комментариев, на том же Хабре.
TheShock
0
Объяснять конкретно в чем ошибки я не хочу" — звучит так же, как у Печкина про посылку

Мне еще больше похоже на
Невероятно, но факт
TheShock
+1
Вот у вас есть экран, на нем пиксели. И пиксели вокруг А и вокруг В — одинаковые. Абстрагируемся от того, что эти пиксели должны символизировать. Де факто 50*50 пикселей что повыше. И 50*50 пикселей что пониже — одинаковые. Но видим мы их как разные. Хотя они одинаковые. И если закрыть все, кроме этих пикселей — мы увидим, что они одинаковые. И они нам кажутся разными не из-за того, что они разные, а из-за цвета пикселей вокруг них. Самое главное — они не разные, они кажутся нам разными.

Вопрос — при чем тут графический редактор?
TheShock
0
Обманул в чем именно? В должно быть темнее или А светлее?
TheShock
0
На Яндексе свет клином не сошелся)
TheShock
0
Плюс этот фиолетовый ловится только если нету фильтра. У обычных фотиков спектр стремится к тому, который первый.
TheShock
0

Интересно. А есть у кого пример программы под такой комп? С разбором кода. Интересно, Как меняется парадигма. Осталось ли понятие переменной? Что считается выходными данными?

TheShock
–1
И тем не менее у моего деда был на работе сотрудник, который водил автобус и ориентировался именно по позиции горящей лампочки.
TheShock
+1
Вы прислали картинку для палочек человеческого глаза, а не для камеры

Ну я же показал фото фильтра Байера. Ну ладно, вот вам другая фото:



Видите, не ловит камера фиолетовый цвет.
TheShock
0
Так настройте баланс белого

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

Матрица фотоаппарата ловит красный, зеленый и синий цвета. а монитор отображает фиолетовый как смесь синего и красного:



Цветок же ж отражает цвет не как смесь красной и синей волны, а как фиолетовая волна длиной, например, 400 нм.



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

Интересно, в дорогих камерах эта проблема решается дополнительными датчиками или как-то еще?

Кстати, аналогичный прикол у меня со светом дома. Есть основное освещение, которое дает естественную картинку вокруг. А есть RGB светодиод. И когда я включаю R+G, то комната вокруг — оранжевого оттенка, но некоторые оранжевые вещи, например футболка или апельсин выглядят как ярко-красные (представляете мандарин цвета клубники?)

Все дело в том, что мандарин отлично отражает желтый и слегка отражает красный, но совершенно не отражает зеленый цвет.

То есть R+G светлодиоды дают пик в, например, 520 нм и 650 нм. В то время как отражательная кривая мандарина начинается (к примеру) с 540 нм и заканчивается на 680 нм.
TheShock
0
Я жене цветы подарил. Вот их фото:


Но дело в том, что в жизни они — фиолетовые. Прям как очень фиолетовые. Ближе к такому, но даже еще более фиолетовые:


Так забавно — смотришь на цветок и на только что сделанное фото — и два совершенно разных цвета. Не просто слегка отличаются, а именно разные цвета
TheShock
+2
А я всегда думал, что индиго значительно ближе к насыщенному фиолетовому.
TheShock
+4
* Не требует доп. софта, Яндекс есть у всех

Не могу с вами согласиться))
TheShock
0
Вопрос в том, есть ли другие дальтоники, о которых мы не можем понять. Которые, к примеру, красный видят как синий, а синий как красный (к примеру, видимый спектр интуитивно). Очевидно, что дейтеранопию диагностировать легко.

С другой стороны, наверное, для такого нарушения должно быть другое название, а не дальтонизм, т.к. дальтонизм — это именно неспособность различать цвета. А в данной ветке говорится о способности различать, но неправильном восприятии.
TheShock
+1
подходящую палитру, например CMYK

А чем она, по сути, отличается от RGB для данной цели?