Условие задачи

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

В битве урон здоровью после удара вычисляется по формуле:

(1) Урон1 = |Защита1 + Уклонение1 – Сила_удара2 – Ловкость2|

Замечания к условию задачи

1. В данном условии на самом деле не нужно пытаться отвечать на поставленный вопрос - этот вопрос, скорее всего, риторического или эмоционального характера.

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

3. В формуле урона есть ошибка, но при проектировании нас это не должно волновать, т.к. величина урона будет вычисляться где-то внутри кода и на проектирование не влияет.

Модель

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

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

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

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

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

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

Реализация модели

В реализации модели использовался интерфейс отображения, чтобы реализацию понятий предметной области изолировать от реализации отображения.

Компиляция

./gomake

Запуск

bin/test