понедельник, 24 октября 2011 г.

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

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


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

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

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

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

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

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

понедельник, 17 октября 2011 г.

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

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

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

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

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

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

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

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

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

воскресенье, 2 октября 2011 г.

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


Один из идеологов объектно-ориентированного подхода и один из авторов языка моделирования UML Джеймс Рамбо пишет:

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

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 42.

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