Использование фреймов в 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

2 2
user-interface delphi information-hiding

2 ответа:

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

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

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

3

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

Пара точек re кадры и информация скрывается в 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 обрабатывает бит, показанный в первом списке. Таким образом, вызывающий код никогда не получает указатель формы и не может коснуться битов, которые не предоставлены специально классом-оболочкой.

0