Regra 1: Crie uma unidade para cada classe (uma classe, uma unidade)
Tenha sempre isso em mente: as partes privadas (PRivate) e protegidas (protegidas) de uma classe ficam ocultas apenas de classes e procedimentos em outras unidades. Portanto, se você deseja um encapsulamento eficaz, você deve fornecer que cada classe A use uma unidade diferente. Para algumas classes simples, como aquelas que herdam de outras classes, você pode usar uma unidade compartilhada. Porém, o número de classes que compartilham a mesma unidade é limitado: não coloque mais de 20 classes complexas em uma unidade simples
Regra 2: Nomeie os Componentes
Também é importante usar nomes descritivos para os componentes. A forma mais comum de nomear é começar com uma letra minúscula da classe, mais a função do componente, como BtnAdd ou editName.
Regra 3: Nomear eventos
É ainda mais importante dar nomes apropriados aos métodos de tratamento de eventos. Se você der ao componente um nome apropriado, o nome padrão do sistema ButtonClick se tornará BtnAddClick. Embora possamos adivinhar a função desse manipulador de eventos pelo nome, acho que é a melhor maneira de usar um nome que descreva a função do método, em vez de usar o nome anexado pelo Delphi. Por exemplo, o evento OnClick do botão BtnAdd pode ser denominado AddToList. Isso tornará seu programa mais legível, especialmente quando você chamar o manipulador de eventos em outros métodos da classe, e ajudará os programadores a escolher o mesmo método para eventos semelhantes ou componentes diferentes.
Regra 4: Use métodos de formulário
Formulários são classes, portanto o código do formulário é organizado por métodos. Você pode adicionar manipuladores de eventos a um formulário. Esses manipuladores executam funções especiais e podem ser chamados por outros métodos. Além dos métodos de manipulação de eventos, você pode adicionar métodos especialmente definidos a um formulário para concluir ações e métodos para acessar o estado do formulário. É melhor adicionar alguns métodos públicos (Public) ao formulário para que outros formulários possam chamar do que para outros formulários operarem diretamente seus componentes.
Regra 5: Adicionar construtores de formulário
O segundo formulário criado em tempo de execução fornece construtores especiais além de um construtor padrão (herdado da classe Tcomponent).
Sugiro que você sobrecarregue o método Create e adicione os parâmetros de inicialização necessários. O código específico pode ser encontrado no seguinte código:
Público
Construtor Create(Text:string): reintroduzir sobrecarga;
Construtor TformDialog.Create(Texto:string);
Começar
Herdado Criar(aplicativo);
Edit1.Text:=Texto;
Fim;
Regra 6: Evite Variáveis Globais
Variáveis globais (aquelas definidas na seção de interface de uma unidade) devem ser evitadas. Abaixo estão algumas sugestões sobre como fazer isso.
Se precisar armazenar dados adicionais para um formulário, você poderá adicionar alguns dados privados à classe do formulário. Neste caso, cada instância do formulário terá sua própria cópia dos dados. Você pode usar variáveis de unidade (variáveis definidas na seção de implementação da unidade) para declarar dados que são compartilhados por diversas instâncias de uma classe de formulário.
Se precisar compartilhar dados entre diferentes tipos de formulários, você pode defini-los no formulário principal para conseguir o compartilhamento, ou usar uma variável global, usar métodos ou propriedades para obter dados.
Regra 7: Nunca use Form1 dentro da classe Tform1
Você deve evitar usar um nome de objeto específico nos métodos da classe. Em outras palavras, você não deve usar Form1 diretamente nos métodos da classe TForm1. Se você realmente precisar usar o objeto atual, poderá usar a palavra-chave Self.
Regra 11: Expor propriedades dos componentes
Quando precisar acessar o estado de outro formulário, você não deve acessar seus componentes diretamente. Porque isso combinará o código de outros formulários ou outras classes com a interface do usuário, e a interface do usuário geralmente é a parte mais mutável de um aplicativo. A melhor abordagem é definir uma propriedade de formulário para a propriedade do componente que você precisa acessar. Para conseguir isso, você pode usar o método Get para ler o status do componente e o método Set para definir o status do componente.
Se agora você precisar alterar a interface do usuário e substituir um componente existente por outro componente, tudo o que você precisa fazer é modificar o método Get e o método Set relacionados às propriedades deste componente, sem ter que localizar e modificar todos os formulários que faça referência a este componente e ao código-fonte da classe. Para métodos de implementação detalhados, consulte o código abaixo:
privado
função GetText:String;
procedimento SetText(const Valor:String);
público
propriedade Texto:String;
leia GetText escreva SetText;
função TformDialog.GetText:String;
começar
Resultado:=Editar1.Texto;
fim;
procedimento TformDialog.SetText(const Valor:String);
começar
Edit1.Text;=Valor;
fim;
Regra 16: Herança de Formulário Visual
Se aplicada corretamente, esta pode ser uma ferramenta poderosa. Pela minha experiência, quanto maior for o projeto que você desenvolve, mais valioso ele será. Em um programa complexo, você pode usar diferentes hierarquias de formulários para lidar com polimorfismo em um grupo de formulários relacionados.
A herança de formulário visual permite compartilhar algumas ações comuns de vários formulários: você pode usar métodos compartilhados, propriedades comuns, até mesmo manipuladores de eventos, componentes, propriedades de componentes, métodos de manipulação de eventos de componentes e assim por diante.
Para obter mais informações, consulte: http://lincosoft.go.nease.net/