Архитектура клиентского приложения (механизмы структуризации)

История первая

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

Игровая компания немца разрабатывала 3 вида игр:

1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

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

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

Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.

На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.

На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.

Далее

Идеальный программист

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

Разработка технологической платформы для игр в условиях временного прессинга

Что такое "технологическая платформа"? Многие, знакомые с областью разработки игр, скажут, что это - графический движок. Предполагается, что если есть инструмент для работы с 3D-объектами, текстурами, камерами, 2D-графикой, то написание игры - дело несложное.

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

При разработке одной игры для девочек для консоли Nintendo Wii автор вместе с коллегами разработал довольно простую технологическую платформу. Используя её, обученный программист мог создавать черновой вариант мини-игры за 3 дня. Потом ещё 2 дня уходили на доделку HUD'а и вставку звука. Итого, создание мини-игры занимало 5 человеко-дней.

Полученным в результате данного проекта опытом я поделился на КРИ 2010. Послушать выступление и посмотреть презентацию можно здесь.

Отзыв на книгу "Шаблоны интеграции корпоративных приложений"

Прочитал книгу:

Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений. : Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.

Книга вышла в серии “A Martin Fowler Signature Book” и посвящена шаблонам интеграции корпоративных приложений.

В настоящее время для интеграции корпоративных приложений используются 4 техники:

1)      Передача файла (File Transfer).

2)      Общая база данных (Shared Database).

3)      Удаленный вызов процедуры (Remote Procedure Invocation).

4)      Обмен сообщениями (Messaging).

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

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

Проектирование игр: функциональный подход

Сегодня выкладываю свою презентацию с КРИ 2008. Она освещает вопросы проектирования видео игр, разумеется, не с гейм-дизайнерской, а с технической точки зрения. В презентации изложены ответы на такие вопросы:

1. К каким проблемам приводят слишком большие иерархии классов?
2. Чем можно заменить такие иерархии?
3. Что брать в качестве основы декомпозиции на подсистемы - функции или объекты?
4. Как проектировать AI-водителя для гоночной игры? (Описание примера.)
5. Чем "грешит" паттерн "Цепочка обязанностей"?

В чём различие между объектно-ориентированным и системным подходами? Часть 1

Объектно-ориентированный подход – это подход к разработке программ. Он был изобретён Кристеном Нюгордом и Оле-Йоханом Далем при разработке языка Симула-67. Впоследствии многие его концепции были развиты Аланом Кеем и Дэном Ингалссом при работе над языком Smalltalk.

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

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

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

Системный подход – это подход к:

Что такое "идеальный код"?

Из обсуждения на форуме RSDN.RU (привожу свои доводы):

Судя по приведенному примеру, Вы предполагаете, что программный код – это набор символов. Но это неправильно! Это все равно, что предполагать, будто дом – набор кирпичей или строительных блоков.

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

0. Символы.

1. Слова (операторы, переменные, константы, типы данных).

2. Функции и функциональные блоки.

3. Типы данных, определяемые пользователем.

4. Иерархии, группы связанных классов.

5. Библиотеки.

6. И т.д. – наверняка что-то пропустил.

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

Задача про датчики: проектирование классов. Часть 2

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

С чего начать проектирование программы? Часть 1.

С чего начать проектирование программы? Часть 2.

Задача про датчики: построение функциональной архитектуры.

Задача про датчики: проектирование классов. Часть 1.

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

В предыдущей статье я предложил условно разделять классы на 2 категории:

1. классы-сервисы:
2. классы-данные.

Классы-сервисы предназначены для выполнения каких-то особых, специфичных задач. Синонимами понятия класс-сервис являются функциональный модуль или функциональная подсистема.

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

Чтобы спроектировать классы-данные, нужно провести анализ потоков данных. Нужно понять, как отдельные функции, выполняемые в рамках процесса, связаны друг с другом по данным. Одним из наглядных инструментов для такого анализа является N-square диаграмма.

Задача про датчики: проектирование классов. Часть 1

Бертран Мейер, один из идеологов объектно-ориентированного подхода, в своей книге "Объектно-ориентированное конструирование программных систем" пишет:

"В формальных и неформальных обсуждениях архитектуры проекта часто задаётся вопрос о роли некоторого класса. И часто можно слышать ответ: "Этот класс печатает результаты" или "Класс разбирает вход" – варианты общего ответа "Этот класс делает...".

Такой ответ обычно указывает на изъяны в проекте. Класс не должен делать одну вещь, он должен предлагать несколько служб в виде компонентов над объектами некоторого типа. Если же он выполняет одну работу, то, скорее всего, имеет место "Большое Заблуждение".

Вполне вероятно, что ошибка не в самом классе, а в способе его описания – использовании операционной фразеологии. Но всё-таки в этой ситуации лучше провести проверку класса".

Мейер, Бертран. Объектно-ориентированное конструирование программных систем / Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2005. – стр. 717.

Если подытожить, то Мейер делает два утверждения:

1. Класс должен отвечать за выполнение нескольких функций.
2. О классе не нужно думать, как о чём-то, выполняющем какие-то обязанности.

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

Проблема эллипса и окружности

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

Одной из проблем, которая порождает подобные дискуссии, является проблема эллипса и окружности. Её можно сформулировать так:

Как с точки зрения объектно-ориентированного подхода правильно объединить в единую иерархию два класса - класс Эллипс и класс Окружность:

Унаследовав Эллипс от Окружности?
Или унаследовав Окружность от Эллипса?

Кейс "Проектирование графического редактора"

Решил объединить свои посты, посвященные вопросам проектирования графического редактора, в отдельный кейс.

1. Общий взгляд на процесс проектирования.

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

2. Постановка задачи, декомпозиция задачи на части.

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

3. Проектирование модуля редактирования.

Серия постов, посвященная проектированию ядра графического редактора, отвечающего за создание и редактирования векторного рисунка:

3.1. Создание функциональной модели.

3.2. Проверка и расширение функциональной модели.

3.3. Проектирование классов.

3.4. Проектирование реализации.

4. Проектирование взаимодействия с пользователем.

Несколько заметок, посвященных вопросам проектирования пользовательского интерфейса и механизма взаимодействия с пользователем.

4.1. Рисование фигур.

4.2. Редактирование фигур.

Проектирование реализации

Цель этапа проектирование классов – найти подходящие классы и определить требования к ним.

Цель этапа проектирование реализации – изобрести реализацию класса, удовлетворяющую требованиям к нему.

В предложенном мною подходе логика проектирования может быть выражена формулой:

Функциональная модель => Группы функций => Кандидаты в классы => Реализация

Проектирование классов

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

Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.

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

Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи  наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.

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

Получается стройная и логичная картина:

class Figure;

class Rectangle : public Figure;

class Ellipse   : public Figure;

class Triangle  : public Figure;

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

Собеседование с архитектором: методические рекомендации

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

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

Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:

(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.

(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.

Попробуем предположить, какой должна быть эта методика.