Архитектура приложения

← →
GreyWolf (2008-06-06 11:42) [0]

У меня есть приложение, интерфейс которого построен так: есть одна главная форма с обыкновенным меню, в меню есть раздел, в котором содержатся команды вызова семи других форм. При выборе одной из них показывается в модальном режиме соответствующая форма. То есть в обработчике OnClick каждого такого пункта меню стоит нечто вроде
ToolForm := TToolForm.Create(nil); try ToolForm.ReadSettings; ToolForm.ShowModal; finally ToolForm.Free; end;
Все ToolForm - наследники TForm
Приложение выполянет различные действия с помощью нескольких объектов. Эти объекты - классы-наследники TComponent, которые я написал ,- являются полями главной формы, создаются в ее OnCreate и уничтожаются при ее закрытии. При совершении того, что на псевдокоде обозначено как ToolForm.ReadSettings соотв. форме передаются ссылки на те объекты, которые данная форма использует. Меня смущает то, что создание набора невизуальных объектов завязано на визуальный компонент - MainForm. Есть ли какой-нибудь более грамотный, красивый подход в Delphi к такой ситуации?

← →
ZENsan © (2008-06-06 11:54) [1]

А можно по русски..а то без пол литра не разоврать чего ты хочешь?

← →
Anatoly Podgoretsky © (2008-06-06 12:00) [2]

> GreyWolf (06.06.2008 11:42:00) [0]

Есть

With TToolForm.Create(nil) do try ReadSettings; ShowModal; finally Free; end; И еще говоришь про завязку, но никакой завязки в коде не видать, как не видать и передачи ссылки.

← →
ЮЮ © (2008-06-06 12:02) [3]

> Меня смущает то, что создание набора невизуальных объектов
> завязано на визуальный компонент  MainForm

Про это не было сказано ни слова. Или все же речь о ToolForm?
Так на форме же что-то отображается? VCL компоненты есть? Или только кнопка "Ok"?

← →
GreyWolf (2008-06-06 15:20) [4]

Передача ссылок происходит для каждой формы вместо строки ReadSettings, например, так:
TfmCalibrator* fmCalibrator = new TfmCalibrator((TComponent*) NULL); __try { fmCalibrator->Calibrator = fCalibrator;//<-здесь fmCalibrator->ShowModal(); } __finally { delete fmCalibrator; }
Под тем, что внутренние невизуальные объекты завязаны на визуальный компонент MainForm - главную форму, имею в виду, что например, объект fCalibrator создается в событии OnCreate главной формы-
void __fastcall TfmBulletAct::FormCreate(TObject *Sender) fCalibrator = new TCalibrator((TComponent*) this);
На всех формах разумеется есть VCL-контролы.

← →
Anatoly Podgoretsky © (2008-06-06 15:30) [5]

Пиши на человеческом языке.

← →
MsGuns © (2008-06-06 16:06) [6]

Сложно разобраться в проблеме, но ИМХО, главный принцип при работе с динамически создаваемыми объектами - это
"ОБЪЕКТЫ ДОЛЖНЫ СОЗДАВАТЬСЯ И УНИЧТОЖАТЬСЯ ТАМ, ГДЕ ИСПОЛЬЗУЮТСЯ"

За исключением, конечно, случаев, когда метод создает объект по требованию извне (по подобию конструкторов)

← →
GreyWolf (2008-06-06 18:29) [7]

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

← →
SergeyIT © (2008-06-06 18:44) [8]

> главная форма слишком сильно связана с внутренними объектами

Так развяжи!

← →
AndreyV © (2008-06-06 19:49) [9]

Прочитав несколько раз
> [0] GreyWolf (06.06.08 11:42)

не понял ничего. Сформулируй яснее.
Далее.

> TfmCalibrator* fmCalibrator = new TfmCalibrator((TComponent*) NULL);

Зачем преобразование типа?

> [7] GreyWolf (06.06.08 18:29)

Ну и пусть владеет, на то она и главная.

> что например, объект fCalibrator создается в событии OnCreate
> главной формы-

В Builder-е лучше делать инициализацию в конструкторе, а не в OnCreate.

← →
GreyWolf (2008-06-06 21:58) [10]

> Зачем преобразование типа?

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

> В Builder-е лучше делать инициализацию в конструкторе, а
> не в OnCreate.

Почему?

Попробую последний раз переформулировать вопрос:
Все невизуальные объекты, с которыми программа постоянно работает, создаются в OnCreate и уничтожаются в OnClose главной формы. Это правильно с точки зрения грамотного построения архитектуры?

> Все невизуальные объекты, с которыми программа постоянно
> работает, создаются в OnCreate и уничтожаются в OnClose
> главной формы. Это правильно с точки зрения грамотного построения
> архитектуры?

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

> [10] GreyWolf (06.06.08 21:58)
>
> > Зачем преобразование типа?
>
> Вы правы, конкретно здесь оно лишнее. В программе до этого
> создается TProgressBar, вот там компилятор ругается, если
> нет преобразования, я видимо вставил его всюду автоматически.

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

>> > В Builder-е лучше делать инициализацию в конструкторе,а не в OnCreate.
> Почему?

Из справки.
Note: Use of the OnCreate event is discouraged in C++ code because it can interact badly with the form"s constructor (see OldCreateOrder). It is recommended that you override the form constructor instead.

> Попробую последний раз переформулировать вопрос:
> Все невизуальные объекты, с которыми программа постоянно
> работает, создаются в OnCreate и уничтожаются в OnClose
> главной формы. Это правильно с точки зрения грамотного построения
> архитектуры?

Правильнее сделать в конструкторе и деструкторе. OnCreate и OnClose более высокоуровневые.
Но задачу ты так и не описал, поэтому мой ответ дан в общем виде.

← →
GreyWolf (2008-06-07 19:29) [13]

Задача следующая: программа является утилитой для программирования и тестирования электронных девайсов. Она выполняет различные процедуры, связываясь с устройством через виртуальный COM-порт, при этом используются объекты типа TDSPModule - для связи с устройством через COM-порт, TToneGen - генератор синуса на звуковой карте, TWaveRec - для оценки уровня сигнала на входе звуковой карты, TTesterModule - по другому COM-порту принимает сигналы с тестера, и некоторые другие. Базы данных не используются. Главная форма - это лог действий, которые в этом сеансе были проведены над подключенными устройствами, со строкой меню сверху для вызова вспомогательных форм для углубленного тестирования некоторых режимов работы.

> Меня смущает то, что создание набора невизуальных объектов
> завязано на визуальный компонент - MainForm.

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

Архитектура приложения Найти похожие ветки