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

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

using System;

string albertName = "Альберт";
int albertMana = 20;

string merlinName = "Мерлин";
int merlinMana = 3;

string edwardName = "Эдвард";
int edwardStamina = 25;

string gleinName = "Глейн";
int gleinStamina = 4;

int CastSpell(string name, int mana)
{
    if (mana < 5)
    {
        Console.WriteLine($"{name}: недостаточно маны.");
        return mana;
    }

    mana -= 5;
    Console.WriteLine($"{name} произносит заклинание. Осталось маны: {mana}");
    return mana;
}

int Attack(string name, int stamina)
{
    if (stamina < 5)
    {
        Console.WriteLine($"{name}: недостаточно выносливости.");
        return stamina;
    }

    stamina -= 5;
    Console.WriteLine($"{name} наносит удар. Осталось выносливости: {stamina}");
    return stamina;
}

albertMana = CastSpell(albertName, albertMana);
merlinMana = CastSpell(merlinName, merlinMana);
edwardStamina = Attack(edwardName, edwardStamina);
gleinStamina = Attack(gleinName, gleinStamina);

Программа делает именно то, что от неё требуется. Альберт произносит заклинание и остаётся с 15 единицами маны, Эдвард атакует и тратит 5 единиц выносливости. Мерлину и Глейну ресурсов не хватает, поэтому функции выводят предупреждения и сохраняют прежние значения. Ни мана, ни выносливость в минус не уходят.

Для короткой демонстрации этого достаточно: решение работает и для четырёх героев остаётся понятным. Однако прототип — это начало проекта, а не его конец, и при расширении требований в коде становятся заметны две проблемы.

Сейчас каждый герой существует как несколько отдельных переменных. Мы понимаем, что albertName и albertMana относятся к одному магу, потому что выбрали похожие имена и держим эту связь в голове. Для самой программы это по-прежнему обычная строка и обычное число, никак не объединённые между собой.

Пока характеристик две, порядок удержать несложно. Но у героя быстро появятся здоровье, уровень, опыт и другие данные. Для нового мага придётся снова создавать весь набор:

string morganaName = "Моргана";
int morganaMana = 12;
int morganaHealth = 100;
int morganaLevel = 1;

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

albertMana = CastSpell(merlinName, albertMana);

Код скомпилируется. Функция получила строку и число нужных типов, поэтому C# не знает, что перед ней имя Мерлина и запас маны Альберта. Ошибка находится не в синтаксисе и не в типах, а в нашем замысле: связанные данные существуют отдельно, и их правильное сочетание пока держится только на внимательности разработчика.

Вторая проблема заметна даже при нынешних четырёх переменных. Обе функции принимают строку и целое число. Для CastSpell число означает ману, а для Attack — выносливость, но тип int не хранит такой смысл. Поэтому мы можем написать следующее:

edwardStamina = CastSpell(edwardName, edwardStamina);
albertMana = Attack(albertName, albertMana);

Для компилятора оба вызова допустимы: функции получили string и int. Для нашей игры они бессмысленны. Эдвард не должен расходовать выносливость на заклинание, а Альберт — ману на удар оружием, но текущее устройство программы не умеет выразить это ограничение.

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

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

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

Программа вокруг объектов

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

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

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

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

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

Возвращаемся к героям

В нашей игре Альберт и Мерлин станут двумя отдельными объектами. Каждый объект будет хранить собственное имя и собственный запас маны, а действие заклинания будет работать с данными именно того мага, к которому мы обратились. Если Альберт потратит 5 единиц маны, значение Мерлина от этого не изменится.

Общий класс Mage опишет, что должно быть у любого мага: имя, мана и возможность произносить заклинания. Сам класс не является Альбертом или Мерлином — это общий шаблон. Альберт и Мерлин будут конкретными объектами, созданными по этому описанию; такие объекты также называют экземплярами класса.

Для Эдварда и Глейна потребуется другое описание — класс Warrior. У воинов тоже есть имя, но вместо маны они хранят выносливость и умеют атаковать. Разделив роли таким образом, мы выражаем правило игры в самой структуре программы: действие заклинания относится к магам, а атака — к воинам.

Это меняет характер ошибки, которую мы видели раньше. Когда функция CastSpell принимает просто строку и число, в неё можно передать данные любого героя подходящих типов. Когда же действие принадлежит объектам типа Mage, у объекта типа Warrior такого действия нет. Попытка заставить воина произнести заклинание уже не выглядит для C# обычным корректным вызовом: компилятор сможет остановить нас до запуска программы.

ООП не требует превращать в объект каждое существительное, встретившееся в условии задачи. Мы сами выбираем сущности, которые важны для программы, и описываем только нужные данные и действия. В нашей тестовой сцене имеет значение имя мага, его мана и заклинание; любимый завтрак Альберта пока можно спокойно оставить сценаристу.

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

В этом уроке мы остановились на концепции. Нам было важно увидеть, почему рабочее процедурное решение становится неудобным при развитии проекта и какое устройство программы нам требуется вместо набора несвязанных переменных. В следующем уроке «Классы, поля и методы» мы перенесём эту модель в C#: опишем классы Mage и Warrior, создадим конкретных героев и увидим, как данные и действия объединяются в коде.