Объектно-ориентированный анализ и проектирование с примерами приложений на С++

DisplayManager();~DisplayManager();void clear();void refresh();void display(Sensor&);void drawStaticItems(TemperatureScale, SpeedScale);void displayTime(const char*);void displayDate(const char*);void displayTemperature(float, unsigned int id = 0);void displayHumidity(float, unsigned int id = 0);void displayPressure(float, unsigned int id = 0);void displayWindChill(float, unsigned int id = 0);void displayDewPoint(float, unsigned int id = 0);void displayWindSpeed(float, unsigned int id = 0);void displayWindDirection(unsigned int, unsigned int id = 0);void displayHighLow(float, const char*, SensorName, unsigned int id = 0);void setTemperatureScale(TemperatureScale);void setSpeedScale(SpeedScale);

protected:// ...};

Ни одна из приведенных операций не является виртуальной, так как создание иерархии классов вывода информации на экран не планируется, и у DisplayManager не будет потомков.

Отметим, что этот класс содержит несколько достаточно примитивных операций (таких, как DisplayTime и refresh), но в то же время обладает составной операцией display, присутствие которой во многом упрощает взаимодействие клиентов с экземпляром класса DisplayManager.

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

Механизм пользовательского интерфейса

Последним основным элементом нашей системы является механизм пользовательского интерфейса, который должен быть реализован с помощью классов Keypad и InputManager. Подобно LCDDevice, класс Keypad служит связующим звеном с аппаратной частью, освобождающим InputManager от необходимости каждый раз приспосабливаться к новому "железу". Разделение этих двух абстракций во многом облегчает процесс адаптации системы к другим аппаратным устройствам ввода информации и повышает степень устойчивости ее архитектуры.

Начнем с определения словаря проблемной области:

enum Key {kRun, kSelect, kCalibrate, kMode, kUp, kDown, kLeft, kRight, kTemperature, kPressure, kHumidity, kWind, kTime, kDate, kUnassigned};

Нам приходится использовать префикс k, чтобы не дублировать наименований типов, уже определенных для SensorName.

Далее, определим класс Keypad следующим образом:

class Keypad {public:

Keypad();~Keypad();int inputPending() const;Key lastKeyPress() const;

protected:...};

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

Класс InputManager имеет во многом аналогичный интерфейс:

class InputManager {public:

InputManager(Keypad&);~InputManager();void processKeyPress();

protected:

Keypad& repKeypad;

};

Как мы увидим, поведение этого класса почти исчерпывающе описывается конечным автоматом.

Рис. 8-13 иллюстрирует взаимодействие классов Sampler, InputManager и Keypad по обработке пользовательских команд. Чтобы интегрировать их, надо несколько видоизменить интерфейс класса Sampler, включив в его описание новый объект repInputManager:

class Sampler {public:

Sampler(Sensor&, DisplayManager&, inputManager&);...

protected:

Sensors& repSensors;DisplayManager& repDisplayManager;InputManager& replnputManager;

};