Regla 1: Crea una unidad para cada clase (Una clase, una unidad)
Tenga siempre esto en cuenta: las partes privada (PRivada) y protegida (protegida) de una clase están ocultas solo para las clases y procedimientos de otras unidades. Por lo tanto, si desea una encapsulación eficaz, debe proporcionar que cada clase A utilice una unidad diferente. Para algunas clases simples, como aquellas que heredan de otras clases, puedes usar una unidad compartida. Sin embargo, el número de clases que comparten la misma unidad es limitado: no pongas más de 20 clases complejas en una unidad simple.
Regla 2: Componentes del nombre
También es importante utilizar nombres descriptivos para los componentes. La forma más común de nombrar es comenzar con una letra minúscula de la clase, más la función del componente, como BtnAdd o editName.
Regla 3: Nombre de eventos
Es aún más importante dar nombres apropiados a los métodos de manejo de eventos. Si le da al componente un nombre apropiado, el nombre predeterminado del sistema ButtonClick se convertirá en BtnAddClick. Aunque podemos adivinar la función de este controlador de eventos por el nombre, creo que es una mejor manera de usar un nombre que describa lo que hace el método, en lugar de usar un nombre adjunto por Delphi. Por ejemplo, el evento OnClick del botón BtnAdd puede denominarse AddToList. Esto hará que su programa sea más legible, especialmente cuando llame al controlador de eventos en otros métodos de la clase, y ayudará a los programadores a elegir el mismo método para eventos similares o componentes diferentes.
Regla 4: utilice métodos de formulario
Los formularios son clases, por lo que el código del formulario está organizado por métodos. Puede agregar controladores de eventos a un formulario. Estos controladores realizan funciones especiales y pueden ser llamados mediante otros métodos. Además de los métodos de manejo de eventos, puede agregar métodos especialmente definidos a un formulario para completar acciones y métodos para acceder al estado del formulario. Es mejor agregar algunos métodos públicos (Públicos) al formulario para que otros formularios los llamen que para que otros formularios operen directamente sus componentes.
Regla 5: Agregar constructores de formularios
El segundo formulario creado en tiempo de ejecución proporciona constructores especiales además de un constructor predeterminado (heredado de la clase Tcomponent).
Le sugiero que sobrecargue el método Create y agregue los parámetros de inicialización necesarios. El código específico se puede encontrar en el siguiente código:
Público
Constructor Create(Text:string): reintroducir;
Constructor TformDialog.Create(Texto:cadena);
Comenzar
Crear heredado (aplicación);
Editar1.Texto:=Texto;
Fin;
Regla 6: Evite las variables globales
Se deben evitar las variables globales (aquellas definidas en la sección de interfaz de una unidad). A continuación se presentan algunas sugerencias sobre cómo hacer esto.
Si necesita almacenar datos adicionales para un formulario, puede agregar algunos datos privados a la clase del formulario. En este caso, cada instancia de formulario tendrá su propia copia de los datos. Puede utilizar variables de unidad (variables definidas en la sección de implementación de la unidad) para declarar datos compartidos por varias instancias de una clase de formulario.
Si necesita compartir datos entre diferentes tipos de formularios, puede definirlos en el formulario principal para lograr compartirlos, o usar una variable global, usar métodos o propiedades para obtener datos.
Regla 7: nunca use Form1 dentro de la clase Tform1
Debes evitar el uso de un nombre de objeto específico en los métodos de la clase. En otras palabras, no debes usar Form1 directamente en los métodos de la clase TForm1. Si realmente necesitas usar el objeto actual, puedes usar la palabra clave Self.
Regla 11: exponer las propiedades de los componentes
Cuando necesites acceder al estado de otro formulario, no debes acceder a sus componentes directamente. Porque esto combinará el código de otras formas u otras clases con la interfaz de usuario, y la interfaz de usuario suele ser la parte más modificable de una aplicación. El mejor enfoque es definir una propiedad de formulario para la propiedad del componente al que necesita acceder. Para lograr esto, puede usar el método Get para leer el estado del componente y el método Set para establecer el estado del componente.
Si ahora necesita cambiar la interfaz de usuario y reemplazar un componente existente con otro componente, entonces todo lo que necesita hacer es modificar el método Get y el método Set relacionados con las propiedades de este componente, sin tener que buscar y modificar todos los formularios que haga referencia a este componente y al código fuente de la clase. Para conocer métodos de implementación detallados, consulte el código a continuación:
privado
función ObtenerTexto:Cadena;
procedimiento SetText(valor constante:Cadena);
público
Texto de propiedad: Cadena;
leer GetText escribir SetText;
función TformDialog.GetText:String;
comenzar
Resultado:=Editar1.Texto;
fin;
procedimiento TformDialog.SetText (valor constante: cadena);
comenzar
Editar1.Texto;=Valor;
fin;
Regla 16: Herencia de forma visual
Si se aplica correctamente, esta puede ser una herramienta poderosa. Según mi experiencia, cuanto más grande sea el proyecto que desarrolles, más valioso será. En un programa complejo, puede utilizar diferentes jerarquías de formas para manejar el polimorfismo en un grupo de formas relacionadas.
La herencia de formularios visuales le permite compartir algunas acciones comunes de múltiples formularios: puede usar métodos compartidos, propiedades comunes, incluso controladores de eventos, componentes, propiedades de componentes, métodos de manejo de eventos de componentes, etc.
Para obtener más información, consulte: http://lincosoft.go.nease.net/