2009-02-14 13 views
20

Después de años de codificar los programas Delphi como código no comprobable en formularios y módulos de datos, incluidas variables globales, y las únicas clases son los formularios en sí, que contienen todo el código que necesito para la forma UI en sí.Cómo/reordenar un programa Delphi utilizando solo formularios y módulos de datos

¿Cómo convertiría el código a un conjunto de clases que hacen el trabajo real? ¿Debería dejar de usar los datasources/datasets y hacer todo en clase? ¿Necesito un ORM?

Por lo general, cero necesita la reutilización del código en los formularios, entonces ¿tiene sentido convertir la lógica en clases?

Respuesta

27

Si encuentro una forma (o de otro tipo) con demasiada responsabilidad, que solemos seguir el patrón a continuación:

  1. Defina una nueva clase para la lógica.
  2. Cree una variable miembro de la clase nueva en el formulario.
  3. Crea la clase en onCreate y libérala en el onDestroy del formulario.
  4. Mueva una sola pieza de la lógica (por ejemplo, una variable) a la nueva clase.
  5. Mueva o cree todos los métodos a la nueva clase.
  6. Compilar y probar.
  7. Continúe hasta que toda la lógica se ponga en la nueva clase.
  8. Intenta desacoplar la clase lógica de la clase de formulario. (Incluso puede trabajar con interfaces si lo desea).

Hay situaciones en las que una sola clase no es suficiente, por lo que no es un problema crear más clases. Y estas clases pueden tener otras clases para.

Con estos pasos, puede resolver la mayoría de estos problemas.

+8

Buenos pasos, pero un consejo: para un acoplamiento mínimo posible, no pases ningún control visual a tus nuevas clases. Si lo haces, entonces restringes tu habilidad para intercambiar controles de UI. Si debe pasar controles visuales (especialmente cuadrículas, etc.) luego aísle todo en otra clase sin lógica comercial. –

+0

Acepto, los controles visibles son responsabilidad del formulario. Es posible usar marcos, pero realmente no me gustan para el código de producción. –

+1

Todos los puntos buenos.¿Qué pasa con la capacidad de prueba de una unidad que se basa en una conexión de base de datos particular y objetos de tablas de datos (TTable, conjuntos de datos ADO o datasnap, etc.) ... –

8

Para empezar Recomiendo leer el libro Refactoring de Martin Fowler.

Esto le dará una comprensión real sobre la mejor manera de abordar de manera sensata la introducción de cambios en el código existente (no OO) para mejorar el mantenimiento.

No miraría un ORM hasta que tenga una idea clara de los beneficios (si corresponde) que aportaría a su aplicación.

1

Después de entender lo que necesita refractario su código, y si quieres un OPF/ORM, que sugieren Jazz SDK

4

Otro libro que puedo recomendar encarecidamente, en mi opinión personal, incluso mejor que el libro de refactorización "genérico" de Fowler - es "Working Effectively with Legacy Code" by Michael Feathers. Realmente muestra los principales baches que golpearás mientras haces ese tipo de trabajo. Ah, y: refactorizar el código heredado puede ser bastante difícil para tu psique. Espero que puedas manejar la frustración ... Me gusta esta cita (no recuerdo de dónde la saqué): "Dios pudo crear el mundo en 6 días, simplemente porque no había ningún código heredado". Buena suerte. ;)

5

He encoured problema como este con una sola aplicación, comienzo haciendo lo siguiente:

  1. definir clases principales para la mayoría lógica general en el código.
  2. En cada formulario, mueva el código que procesa la lógica comercial dentro de los eventos como función/procedimientos en esa forma.
  3. Luego, mueva estas funciones/procedimientos a esas clases como métodos estáticos.
  4. Finalmente haga solo el código necesario dentro de formularios como la IU de validación y las llamadas a las clases.
  5. Para las variables globales trate de omitir todo lo que pueda, y simplemente pase los valores como parámetros a los métodos.

Utilicé métodos estáticos, porque es más fácil para usted eliminar el código de eventos y simplemente llamarlos sin tener que crear/Objeto libre para cada operación. El diseño original no fue diseñado para separar los formularios del código de lógica de negocios.

La aplicación final no era completa OO, pero al menos era más fácil probar los métodos sin necesidad de interactuar con los formularios y eventos como antes.

A veces sientes que si rediseñas la aplicación desde cero será más fácil que hacer cambios para que sea real.

4

Importar en Modelmaker es mi primera acción cuando me enfrento a un proyecto Delphi existente. Modelmaker le ayudará a refactorización el código porque:

  • Se gráficamente representa todas las clases, métodos, variables, etc.
  • Está muy bien integrado en el IDE de Delphi (menú principal , menú emergente, explorador Modelmaker por separado, barra de herramientas , atajos de teclado). Este integración le permite rápida realizar las acciones necesarias sin dejando el IDE
  • Tiene un dedicado "refactoring" módulo de que le permite crear de forma rápida, mover y cambia el nombre de clases y variables sin tener que preocuparse de cambiar el código subyacente . Modelmaker será automágicamente cambiar los nombres y referencias en todas las unidades.

La funcionalidad básica de Modelmaker es fácil de aprender. Modelmaker es como cualquier otra herramienta de buena productividad: cuanto más le dedicas, más lo sacas. Modelmaker no es gratuito, pero se paga fácilmente a sí mismo en una mayor productividad. No he encontrado una herramienta mejor para refactorizar el código Delphi heredado. Ofrecen una versión de prueba gratuita y algunas películas tutoriales decentes. Prueba Modelmaker y buena suerte ...

+0

Nada en contra de ModelMaker, pero todas las cosas que ha mencionado están incorporadas hoy en día. Aún así, +1 por ser útil en caso de que tengas un Delphi más viejo. –

+0

Gracias - Todavía estoy usando Delphi 5. Sé que los chicos de Modelmaker tenían un acuerdo de código compartido con Borland. Gran parte de la funcionalidad de Modelmaker se integró en Delphi IDE. Supongo que si toda la funcionalidad de Modelmaker está integrada en el IDE, entonces nadie gastará 199 euros en una licencia. –

+1

@Kris, En realidad, la funcionalidad de refactorización integrada no es de ModelMaker sino de Borland Together (que es MUCHO más antipático). Utilicé ambos modelos predeterminados de Delphi y ModelMaker es mucho más fácil de entender para un desarrollador de Delphi. –

Cuestiones relacionadas