How / if to refactor a Delphi program using only forms and data modules

Question

After years of coding Delphi programs as untestable code in forms and datamodules, including global variables, and the only classes are the forms themselves, containing all

Answer 1

If I encounter a form (or other class) with too much responsibility, I usualy follow the pattern below:

1. Define a new class for the logic.
2. Create a member variable of the new class in the form.
3. Create the class in the onCreate and free it in the onDestroy of the form.
4. Move a single piece of logic (for example a variable) to the new class.
5. Move or create all methods to the new class.
6. Compile and test.
7. Continue until all logic is put in the new class.
8. Try to decouple the logic class from the form class. (You can even work with interfaces if you like).

There are situations where a single class is not enough, so it is no problem to create more classes. And these classes can have other classes to.

With these steps, you can tackle most of these problems.

Answer 2

Importing into Modelmaker is my first action when confronted with an existing Delphi project. Modelmaker will assist you in refactoring your code because:

• It graphically represents all the classes, methods, variables, etc.
• It is very tightly integrated in the Delphi IDE (main menu, popup menu, separate Modelmaker explorer, toolbar, keyboard shortcuts). This integration allows you to quickly perform the necessary actions without leaving the IDE
• It has a dedicated "refactoring" module allowing you to quickly create, move and rename classes and variables without having to worry about changing the underlying code. Modelmaker will automagically change names and references in all units.

The basic functionality of Modelmaker is easy to learn. Modelmaker is like any other good productivity tool - The more you put into it, the more you get out of it. Modelmaker is not free but easily pays for itself in increased productivity. I have not found a better tool for refactoring legacy Delphi code. They offer a free trial and some decent tutorial movies. Give Modelmaker a try and good luck...

Answer 3

After understand what you need to refactory your code, and if you want an OPF/ORM, I suggest Jazz SDK

Answer 4

Another book I can highly, highly recommend - in my personal opinion even better suited than the "generic" refactoring book by Fowler - is "Working Effectively with Legacy Code" by Michael Feathers. It truly showcases the major bumps you will hit while doing that kind of work. Oh, and: Refactoring legacy code can be quite hard on your psyche. I hope you can handle frustration... I like this quote (don't remember where I got it from): "God was able to create the world in 6 days, just because there wasn't any legacy code". Good luck. ;)

Answer 5

I have encoured problem like this with one application, I start doing the following:

1. Define main classes for most general logic in the code.
2. In each form, move the code that process the business logic inside the events as function / procedures in that form.
3. Then Move these functions/procedures to those classes as static methods.
4. Finally make only the needed code inside forms like validation UI, and calls to the classes.
5. For the global variables try to omit as much as you can, and just pass the values as parameters to the methods.

I used static methods, because it's easier for you to remove the code from events and just call them without requiring to Create/Free object for each operation. The original design was not designed to separate the forms from business logic code.

The final application was not full OO, but it least it was easier to test the methods without requiring interacting with the forms and events like before.

Sometimes you feel if you redesign the application from scratch it will be easier than to made changes to make it real OO design.

Answer 6

To start with I can highly recommend reading the book Refactoring by Martin Fowler.

This will give you a real understanding about how best to sensibly approach introducing changes to the existing (non OO) code to improve maintainability.

I would not look at an ORM until you have a clear understanding about what benefits (if any) one would bring to your application.