I have a large codebase which I am working with which has units like this:
unit myformunit;
interface
type
TMyForm = class(Form)
end;
procedure not_a_method1;
procedure not_a_method2;
var
global1,global2,global3:Integer;
...
In short, the authors of the code did not write methods, they wrote global procedures. There are tens of thousands of them. Inside these procedures, they reference a single instance of MyForm:TMyForm
.
I am considering writing a parser/rewriter utility that will turn this code into "at least minimally object oriented code". The strategy is to move the interface and implementation section globals into the form, as a start. I realize that's hardly elegant OOP. But it's a step forward from globals.
If I could do this on one unit at a time, I might be able to repair the breakage in the rest of the project, if I only did it on one form at a time. But I'd like to reduce the amount of time it takes to rewrite the units, instead of doing it by hand. Some forms have 500+ procedures and 500+ interface and implementation global variables which are in fact, specific to the state of a single instance of the form that they are in the same unit with.
Basically, what I will do if nothing like this exists is write a parser based on the Castalia Delphi parser. I'm hoping that perhaps ModelMakerCodeExplorer, or castalia, or some other similar tool has something that would at least do part of what I need for me, so I don't have to build this utility myself. Even if I do have to build it myself, I estimate it might automate about a thousand to two thousand hours of grunt-work for me. I can at least run it, and then see how much breaks, and then revert or commit after I've decided on a level of effort to refactor this code.
Alternative strategies that accomplish the same goal (go from zero encapsulation and zero OOP, to more encapsulation, and slightly more than zero OOP, in an incremental way, on a large, unstructured delphi codebase that only used objects when it was unavoidable, and never had any idea about real OOP) are welcomed.
Changing the globals to form fields seems like just cut and paste them. You might consider moving them in a dummy procedure and use MMX to normalize the declarations first.
Then use ModelMaker Code Explorer to move the procedures and functions into the form, which is only just cut and paste in the Member View.
Not necessary, but as a next step remove the references to the form instance from the method bodies. This can be achieved by find and replace.
Or did I miss something?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With