1.4 Описание интерфейсов модулей (дата сдачи: 15.10)

После того как список модулей был выбран нужно определить интерфейсы этих модулей – как они будут взаимодействовать между собой. Интерфейсы это обычные абстрактные классы (в терминологии C++), которые начинаются с заглавной буквы “I”, например: IGame, ILogic, IJournal, IEvenHandler и т.д. От этих интерфейсов наследуется реальный класс, который имплементирует все виртуальные функции интерфейса. Проектирование интерфейсов – очень важная и ответственная задача. Как правило, интерфейсы проектируется один раз и на очень долгое время, а реальные объекты за интерфейсами могут меняться. Например пусть у нас есть интерфейс IJournal, в котором есть метод save( );, который где-то сохраняет журнал. За интерфейсом мы понятия не имеем какой на самом деле стоит журнал, это может быть FileJournal, NetJournal, DBJournal и вообще, что угодно. Главное чтобы класс, который наследуется от интерфейса определил у себя функцию save() иначе, интерфейс не будет работать.

1.5 Выбор паттернов проектирование и наложение на архитектуру (дата сдачи: 29.10)

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

1.6 Написание тестов на интерфейсы и модули (дата сдачи: 12.11)

Начинать написание тестов следует с интерфейсов. Создается класс-пустышка (в терминологии фреймворка тестирования google: Mock - объект), который пытается описать как должен вести себя реальный класс. Этот класс-пустышка наследуется от интерфейса и пытается имитировать работу всех его методов, чтобы это было похоже на то, как будто за интерфейсом находится реальный объект. Такое поведение сделать достаточно просто, т.к. пользователь интерфейса не видит всего что должно происходить в реальном объекте и может контролировать только ограниченный набор данных, которые предоставляет интерфейс. Например, вызвав метод интерфейса, который называется int getSceneObjectsCount(), тот, кто вызвал этот интерфейс, ожидает что этот метод вернет какое-то положительное число или бросит исключение, если сцена отсутствует.

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

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

Если для написания игры будет использоваться язык C++, рекомендуется использовать тестирующий фрейворк от google: googletest