Помогите с архитектурным решением

← →
бабба (2005-11-09 22:45) [0]

Здравствуйте, хочется все сразу делать красиво и элегантно, но такого опыта с ООП проектированием у меня нет.
Есть след. задача:
Есть девайс, у него есть драйвер. Надо с девайсом работать. Действия несложные: режим show only, когда данные просто отображаются на экране (как осциллограф)
режим record, когда данные льются на винт, пару раз в секунду можно отображать на экране
режим playback, когда из открытого файла или только записанного идет показ данных.
Вот и все.
Как это в духе ООП сделать? Не утруждайте себя постами типа "MVC тебе поможет"

Я думаю так:
Есть класс документа, он взаимодейтвует с объектом контроллер и объектом драйвер, имеет в себе объект ДатаФайл.
Есть класс View, он получает данные, копирует их буфер и при надобности перерисовывает себя.
На контроллер завязаны все Action"ы.
Или не так?

← →
Игорь Шевченко © (2005-11-09 22:54) [1]

> Или не так?

На первый взгляд вроде все так.

> Есть класс документа, он взаимодейтвует с объектом контроллер
> и объектом драйвер, имеет в себе объект ДатаФайл.

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

← →
Sandman29 © (2005-11-10 09:16) [2]

>Документ, опять же, не взаимодействует, скорее всего, с объектом драйвер, а инкапсулирует его

ИМХО лучше не инкапсулировать, а взаимодействовать (использовать). То есть документ не должен быть драйвером ни в коем случае. Хотя в параметрах конструктора документа вполне может быть экземпляр драйвера.
А вообще очень рекомендую почитать о паттернах, чтобы уменьшить число неясностей.
http://ooad.asf.ru/patterns/viewpattlist.asp?cat=0

← →
Игорь Шевченко © (2005-11-10 10:32) [3]

Sandman29 © (10.11.05 09:16) [2]

> Хотя в параметрах конструктора документа вполне может быть
> экземпляр драйвера.

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

← →
Sandman29 © (2005-11-10 10:43) [4]

Игорь Шевченко © (10.11.05 10:32) [3]

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

← →
Игорь Шевченко © (2005-11-10 10:53) [5]

Sandman29 © (10.11.05 10:43) [4]

Это я слово перепутал. Не агрегирование, а композиция, как альтернатива наследованию. Насчет создаваться по требованию - а какой смысл ?

Игорь Шевченко © (10.11.05 10:53) [5]
Насчет создаваться по требованию - а какой смысл ?

В данном случае - никакого. Согласен.

← →
iZEN_ (2005-11-10 14:08) [7]

Подходит паттерн проектирования Стратегия.
* Стратегия "show only", когда данные просто отображаются на экране (как осциллограф);
* Странтегия "record", когда данные льются на винт, пару раз в секунду можно отображать на экране;
* Стратегия "playback", когда из открытого файла или только записанного идет показ данных.
Можно воспользоваться преимуществами наследования, когда класс стратегии "Playback" наследуется от класса стратегии "Showonly" с добавлением режима перемотки. Класс стратегии "Record" - уже отдельный.

Помогите с архитектурным решением Найти похожие ветки