Cómo separar el código de interfaz y el código de función (basado en Delphi/VCL)

Después de leer "Creación de código bien diseñado (basado en Delphi/VCL)" que escribí la última vez, muchos amigos me dijeron que sentía que podía aceptar los puntos de vista que contenía, pero parecía demasiado simple y no lo suficientemente específico; Algunos amigos también expresaron dudas al respecto. Un pequeño ejemplo de algunas objeciones. De ahí este artículo.

La última vez, el ejemplo que di fue este: Supongamos que desea obtener una lista de cadenas de algún lugar y luego mostrarla en un TListBox. El código que recomiendo es:

ObjetoXXX := TObjectXXX.Create;

ListBox1.Items := ObjetoXXX.GetStringList;

ObjetoXXX.Gratis;

De hecho, admito que, a juzgar únicamente por estas tres líneas de código, parece sospechoso de "abuso de objeto". Quizás el ejemplo sea demasiado simple y dé la impresión de que TObjectXXX solo tiene una función miembro pública, GetStringList. Si esto es cierto, en realidad es "abuso de objeto". Una clase es una abstracción de un objeto y un objeto se compone de una colección de estados y operaciones (es decir, datos y operaciones sobre datos). Por lo tanto, ¡un objeto sin estado no es un objeto! El diseño de una clase sin miembros con datos privados es un diseño fallido (es decir, no es una clase, sino una interfaz).

Bien, déjame darte un ejemplo detallado para ilustrar cómo separar el código de interfaz y el código de función.

Supongamos que quiero crear un software de administración de libreta de direcciones personal simple. Obviamente, todo el software se divide en dos partes: una parte está orientada al usuario, que es la llamada parte de interfaz, puedo proporcionar cuatro botones (respectivamente "agregar"). , " "Eliminar", "Modificar", "Buscar") y un cuadro de edición (que muestra información de la libreta de direcciones y acepta entradas del usuario) se utilizan para interactuar con el usuario; la otra parte es funcional, es decir, la operación de acceso del libreta de direcciones dentro del software.

Entonces, existe una clase TAddrBook, que es una abstracción de la parte funcional.

TAddrBook = clase

Privado

//Algunos miembros privados

público

constructor Crear;

destructor Destruir; anular;

GetCount: Entero;

FindRecord(strString): entero;

GetRecord(nIndex:Entero): Cadena;

SetRecord(nIndex:integer; strRec:String): booleano;

AddRecord(strRec:String): booleano;

DelRecord(nIndex): booleano;

//Otras funciones miembro compartidas

fin;

La razón por la que no se pueden determinar los miembros privados depende principalmente de la implementación de esta clase.

De esta forma se puede encapsular la lógica de las operaciones de acceso a la libreta de direcciones. El código en la parte de la interfaz no involucrará estas lógicas de acceso. El código de la parte de la interfaz es el siguiente:

var

Formulario1: TForm1;

Libro de direcciones: TAddrBook;

nCurRec: Entero;

implementación

procedimiento TForm1.FormCreate(Remitente: TObject);

comenzar

AddrBook := TAddrBook.Create;

nCurRec := AddrBook.GetCount;

fin;

procedimiento TForm1.FormClose(Remitente: TObject; var Acción: TCloseAction);

comenzar

AddrBook.Gratis;

fin;

//Añadir botón

procedimiento TForm1.Button1Click (Remitente: TObject);

comenzar

si no es AddrBook.AddRecord(memo1.Text) entonces

MostrarMensaje("error");

fin;

// boton eliminar

procedimiento TForm1.Button2Click (Remitente: TObject);

comenzar

si no es AddrBook.DelRecord(nCurRec) entonces

MostrarMensaje("error");

fin;

//botón modificar

procedimiento TForm1.Button3Click(Remitente: TObject);

comenzar

si no es AddrBook.SetRecord(nCurRec, memo1.Text) entonces

MostrarMensaje("error");

fin;

//botón buscar

procedimiento TForm1.Button4Click (Remitente: TObject);

comenzar

memo1.Text := AddrBook.GetRecord(AddrBook.FindRecord(memo1.Text));

fin;

El código en la parte de la interfaz anterior no implica ninguna lógica de acceso. El código de cada módulo es simple, fácil de entender y fácil de mantener. De hecho, el código de la interfaz no sabe si la libreta de direcciones está guardada en una base de datos o en un archivo de texto. Si se utiliza una base de datos, si se accede a la base de datos a través de ODBC, ADO o BDE, el código de la interfaz no lo sabe. De hecho, estas lógicas de acceso dependen de la implementación de la clase TAddrBook. La implementación de la clase TAddrBook se puede colocar en un archivo .pas separado. Cualquier cambio en la implementación de la clase TAddrBook no afectará la parte de la interfaz. Al mantener el código, es aconsejable limitar los cambios a un solo módulo.

Nicrosoft ([email protected]) el 2001.7.14