Uso de quadros em Delphi para obter informações GUI esconderijo

Question

tenho vindo a aprender Delphi para os últimos 3 anos, em um nível passatempo / ocupacional. Estou feliz em dizer que eu agora ter progredido ao ponto que eu posso olhar para trás em meu código cedo com horror e constrangimento. Então agora estou passando por alguns dos meus primeiros aplicativos e reescrever / refatoração-los.

Um dos maus hábitos que eu estou tentando ficar longe está acessando componentes em um formulário de outra unidade. Em um esforço para impor isso, eu tenho experimentado com o uso de frames como um método de ocultação de informações. Então, ao invés de ter um formulário com componentes nele, eu estou criando um quadro para conter todos os componentes de formulário, em seguida, colocar a moldura em um formulário, movendo-se a declaração quadro em declarações privadas,

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

, em seguida, registrar o quadro na seção de forma inicialização

initialization 
begin
RegisterClasses([TMyFrame])

Estou em seguida, declarar as propriedades que eu preciso na seção pública da unidade de forma, que tem acesso à estrutura e seus componentes.

  public
    property TimeDate: TOverlayItem  read ReadTimeDate  write SetTimeDate;

Também estou usando quadros para consolidar grupos de componentes, muitas vezes repetidas.

Isso parece funcionar para os fins que eu quero (escondendo MyFrame e seus componentes), mas Alguém tem alguma experiência desse método?

Há alguma desvantagem com o uso de frames? Estou realmente ganhar qualquer benefício de fazer isso? Há algum problema com o uso de quadros aninhados dentro de quadros? Há algum guias de boas práticas para o uso de frames em Delphi? Há melhor / maneiras mais fáceis de alcançar o mesmo efeito no que diz respeito à informação GUI esconderijo em Delphi?

HMcG

Answer 1

Parece que você ainda está tendo muita lógica em sua camada de interface do usuário. Formulários / Painéis não deveria ter que as propriedades muito valor (exceto talvez para diálogos).

Se você quiser mais estrutura do que ler sobre o padrão MVC.

Dito tudo isso, Frames pode ser uma boa maneira de organizar a GUI. Como com tudo, não fazer uso excessivo.

Answer 2

Eu como quadro geral para a criação de pedaços reutilizáveis ??complexas. Para a maior parte eu acho que eles podem ser uma maneira realmente limpo para construir telas. No entanto, como mencionado por Henk Holterman suas telas e quadros só deve conter a lógica relacionada com o funcionamento da interface do usuário e ser tão ignorantes quanto possível sobre a lógica de negócios.

Um par de pontos re quadros e ocultação de informações na interface do usuário:

1. Como discutido em outra pergunta sobre StackOverflow você precisa ter cuidado ao usar manipuladores de eventos em seu quadro.
2. Frames ainda tem muitas propriedades publicados e realmente não resolver o problema de formas que são capazes de mexer indevidamente com o outro é pedaços. Mesmo se você não fazê-lo, se o código permite que alguém vai código, eventualmente gravação que tampers onde não deve. Eu sempre remover a variável de formulário Delphi global sullies o código com e muitas vezes escrever invólucro objetos ou implementar interfaces que permitem o acesso à UI controlados.

Então, ao invés de ter um código como este:

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

Eu vou geralmente forçar as pessoas a escrever algo do tipo:

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

ou mesmo

TClientViewer.ShowClient(MyClient);

e ter o método de classe ShowClient lidar com o pouco mostrado na primeira listagem. Dessa forma, o código de chamada nunca recebe o ponteiro forma e não pode tocar qualquer bits que não são oferecidos especificamente pela classe wrapper.