Использование фреймов в Delphi для сокрытия информации графического интерфейса пользователя

Я изучаю Delphi последние 3 года на уровне хобби / профессии. Я счастлив сказать, что сейчас я продвинулся до такой степени, что могу оглядываться на свой ранний код с ужасом и смущением. Итак, сейчас я просматриваю некоторые из моих ранних приложений и переписываю / реорганизую их.

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

type
  TMyForm = class(TForm)
   private
    MyFrame: TMyFrame;
    procedure SetTimeDate(const Value: TMyItem);
    function ReadTimeDate:TMyItem ;

затем регистрируем фрейм в секции инициализации формы

initialization 
begin
RegisterClasses([TMyFrame])

Затем я объявляю нужные мне свойства в общедоступном разделе модуля формы, у которого есть доступ к фрейму и его компонентам.

  public
    property TimeDate: TOverlayItem  read ReadTimeDate  write SetTimeDate;

Я также использую рамы для объединения часто повторяющихся групп компонентов.

Кажется, это работает для тех целей, которые я хочу (скрытие Myframe и его компонентов), но есть ли у кого-нибудь еще опыт этого метода?

Есть ли недостатки в использовании рамок? Получаю ли я от этого какую-то пользу? Есть ли проблемы с использованием вложенных фреймов внутри фреймов? Есть ли какие-нибудь полезные руководства по использованию фреймов в Delphi? Есть ли лучшие / более простые способы достижения того же эффекта в отношении скрытия информации графического интерфейса в Delphi?

HMcG


user-interface delphi vcl information-hiding
person HMcG    schedule 23.07.2009    source источник
comment
Для чего вам нужны RegisterClasses ([TMyFrame])?   -  person Uli Gerhardt    schedule 23.07.2009
comment
Поскольку я перемещаю MyFrame: TMyFrame; в частный раздел возникает исключение, в котором говорится, что TMyFrame не найден, если я не зарегистрирую TMyframe.   -  person HMcG    schedule 25.07.2009
comment
Вы должны сосредоточиться на том, как уменьшить сцепление в своем дизайне, чтобы в конечном итоге не имело значения, используете ли вы фреймы или нет. Мне очень поучительна следующая статья: objectmentor.com/resources/articles/TheHumbleDialogBox.pdf   -  person mghie    schedule 26.07.2009

Ответы (2)


arrow_upward
3
arrow_downward

Похоже, у вас все еще есть много логики на уровне пользовательского интерфейса. Формы / панели не должны иметь столько свойств значений (за исключением, может быть, диалогов).

Если вам нужно больше структуры, чем читайте в шаблоне MVC.

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

person Henk Holterman    schedule 23.07.2009
comment
Вы совершенно правы в том, что в моих ранних приложениях была вся логика на уровне пользовательского интерфейса. Итак, я хотел бы чистый способ поднять значения / свойства пользовательского интерфейса для использования в основном модуле приложения. Большинство моих приложений взаимодействуют с оборудованием и выполняют довольно простые операции, но с большим количеством конкретных настроек, поэтому неясно, как уйти от формы (диалогов?), Имеющих множество свойств Value. Я работаю (медленно) над книгой Head First Design Patterns, поэтому я скоро перейду к MVC. Я надеялся на более чистый стиль RAD для простых инструментов / приложений. - person HMcG; 25.07.2009
comment
RAD не приведет вас к лучшему дизайну. Рассмотрите возможность создания объекта Settings, с которым может работать форма. - person Henk Holterman; 26.07.2009
comment
Итак, я создаю запись или класс, значения которого устанавливает логика на уровне графического интерфейса пользователя, а затем получаю доступ к этому объекту в основном модуле? Похоже, это лучший метод, чем наличие набора свойств в модуле формы графического интерфейса. Спасибо. - person HMcG; 26.07.2009
comment
Ага - это называется уровнем бизнес-правил - person Henk Holterman; 26.07.2009

arrow_upward
0
arrow_downward

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

Пара моментов по поводу кадров и скрытия информации в UI:

  1. Как обсуждалось в другом вопросе по StackOverflow, вам нужно быть осторожным при использовании обработчиков событий в вашем фрейме.
  2. Фреймы по-прежнему имеют множество опубликованных свойств и на самом деле не решают проблему того, что формы могут некорректно возиться с битами друг друга. Даже если вы этого не сделаете, если код позволяет это, кто-то в конечном итоге напишет код, который вмешивается там, где этого не должно быть. Я всегда удаляю глобальную переменную формы. Delphi искажает код и часто пишу объекты-оболочки или реализую интерфейсы, обеспечивающие контролируемый доступ к пользовательскому интерфейсу.

Поэтому вместо такого кода:

ClientForm := TClientViewForm.Create(Self);
try
  ClientForm.Client := MyClient;
  ClientForm.ShowModal;
finally
  ClientForm.Free;
end;

Я обычно заставляю людей писать что-нибудь в этом роде:

ClientViewer := TClientViewer.Create(MyClient);
try
  ClientViewer.Show;
finally
  ClientViewer.Free;
end;

или даже

TClientViewer.ShowClient(MyClient);

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

person Cobus Kruger    schedule 23.07.2009
comment
Спасибо за указание 1) - я еще не сталкивался с этим. Пункт 2) - это то, что я делаю с частным MyFrame - только модуль MyForm, связанный с Frame, может получить доступ к Frame и компонентам frame. Ни один из других модулей не может видеть (частный) MyFrame. Если метод класса-оболочки имеет такой же эффект, это, вероятно, будет более простым способом достижения того же эффекта. HMcG - person HMcG; 25.07.2009