Cómo/si refactorizar un programa Delphi utilizando solo formularios y módulos de datos

unit-testing oop

Question

Después de años de codificar programas Delphi como código no comprobable en formularios y módulos de datos, incluidas las variables globales, y las únicas clases son los formularios en sí, que contienen todo el código que necesito para la interfaz de usuario del formulario.

¿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, no es necesario reutilizar el código en los formularios, de modo que ¿tiene sentido convertir la lógica en clases?

Answer 1

Después de entender lo que necesita para refactorizar su código, y si desea un OPF / ORM, sugiero Jazz SDK

Answer 2

He encontrado un problema como este con una aplicación, empiezo a hacer lo siguiente:

1. Defina las clases principales para la lógica más 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 los eventos y simplemente llamarlos sin tener que crear un objeto / Free 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 estaba llena de 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 un diseño real de OO.

Answer 3

Importar en Modelmaker es mi primera acción cuando me enfrento a un proyecto existente de Delphi. Modelmaker lo ayudará a refactorizar su código porque:

• Representa gráficamente todas las clases, métodos, variables, etc.
• Está estrechamente integrado en Delphi IDE (menú principal, menú emergente, explorador de Modelmaker por separado, barra de herramientas, atajos de teclado). Esta integración le permite realizar rápidamente las acciones necesarias sin abandonar el IDE
• Tiene un módulo dedicado de "refactorización" que le permite crear, mover y cambiar el nombre de clases y variables rápidamente sin tener que preocuparse por cambiar el código subyacente. Modelmaker cambiará automágicamente 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, sino que se paga fácilmente a sí mismo con 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 ...

Answer 4

Otro libro que recomiendo mucho, en mi opinión personal, incluso mejor que el libro de refactorización "genérico" de Fowler, es "Trabajar eficazmente con el código heredado" de 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. ;)

Answer 5

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 solicitud.

Answer 6

Si encuentro un formulario (u otra clase) con demasiada responsabilidad, generalmente sigo el siguiente patrón:

1. Defina una nueva clase para la lógica.
2. Cree una variable miembro de la nueva clase en el formulario.
3. Cree la clase en onCreate y libérela en el onDestroy del formulario.
4. Mueva una sola pieza de lógica (por ejemplo, una variable) a la nueva clase.
5. Mueva o cree todos los métodos a la nueva clase.
6. Compila y prueba.
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 abordar la mayoría de estos problemas.