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

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

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

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

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

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

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

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

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

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

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

Почему надо проектировать "от обязанностей", или сколько функций выполняет чашка?

В одном из комментариев к своей статье, желая подчеркнуть важность учёта обязанностей при проектировании программы, я написал:

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

Один из коллег в личной переписке на это возразил:

1. Если задумываться о назначении чашки, то будет сложно налить в чайную чашку кофе, а в кофеную – чай.
2. Гораздо проще снабдить обычную чашку двумя интерфейсами – "налить кофе" и "налить чай".

В качестве возражения на это замечание коллеги мне бы хотелось сказать вот что...

О том, как путают функциональный подход к проектированию с процедурным программированием

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

Пример 1. Проектирование графического редактора

Пример 2. Проектирование программы для метеостанции

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

Какие же недостатки приписывают функциональному подходу?

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

Просмотрел сильно разрекламированную книжку Мартина Фаулера «Архитектура корпоративных приложений» (точная ссылка: Фаулер, Мартин. Архитектура корпоративных приложений.: Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с.: ил.). Книжка описывает архитектурные паттерны, которые можно использовать при разработке корпоративных (как правило, web-based) приложений. Поскольку такие приложения практически не обходятся без использования базы данных, очень много места в книжке уделяется объектно-реляционному отображению.

А. Общие впечатления.

Основные впечатления от книжки:

1)       Книга не содержит описания архитектур, хотя в названии используется слово «архитектура». Книга содержит отдельные частные решения, которые можно использовать при проектировании – и только-то!

2)       Книга не содержит перечня архитектурных задач (хотя бы неполного). Отсутствует какая-либо модель постановки задач при разработке архитектуры. Что такое творческая задача в архитектуре? Автор об этом умалчивает.

3)       Поскольку описание задач отсутствует, нет критерия для отбора паттернов. Паттерны включены в книгу в произвольном порядке. Приведенные решения не разделены на качественные уровни. В результате «слабые» паттерны соседствуют вместе с «сильными».

4)       Многие паттерны образованы по схеме: «преобразование + объект, к которому оно применяется». В результате паттерны дублируются. Хоть преобразования, лежащие в их основе, одинаковые, но вот объекты разные.

Вывод:

Как специалисты по эргономике формулируют задачу по оценке качества интерфейса?

Цитата:

"Во многих исследованиях по оценке деятельности операторов задаётся простой вопрос: какая интерфейсная система лучше – A или B? Это пример плохо сформулированной задачи, и результаты последующих усовершенствований почти наверняка будут разочаровывающими., т.е. они будут не очень информативными по сравнению с затратами на их получение. Поскольку интерфейсы используются для сообщения данных оператору в целях оказания помощи при выполнении рабочих заданий, то, как минимум, вопрос об оценке должен задаваться в такой форме:

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

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

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

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

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

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

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

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

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