The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Tools to convert static C# classes to "normal" ones

Due to some bad design decisions, my project consists of a bunch of static functions in separate classes and projects. The interface calls functions in classes in the business-logic layer, which call functions in the DB layer, etc.

Now, we need to change it so that the functions are non-static. That means instantiating objects for a class (passing the necessary constructor parameters) and changing the function calls to use those objects.

Changing the classes themselves is easy. Changing the calling code is going to be painful. What is the easiest way to do it? Are there any refactoring tools that can handle it?
Tuesday, July 12, 2005

Is there any pattern to the calling process?  If there is a pattern, then you can write some kind of refactoring tool that takes into account your specific pattern.  Example:

StaticClass.StaticMethod(arg1, arg2);

can become:

InstanceClass ic = new InstanceClass(arg1, arg2);


InstanceClass ic = new InstanceClass(arg1);

If you can find some kind of calling pattern, then you could have something rewrite your code for you. 

If each call has to be different for each instance class, then you might want to do something where you are specific about the string replacement.  Imagine an XML file that contains the original code, and what the code should look like for that specific example.  Then you can write a program to do the find and replace (probably recursively through your directory structure). 

Your other option seems arcane to me, but it might work.  Change all the classes, try to compile.  This will give you a list of all the places where the classes are getting called improperly (post change).  I would do this one class at a time. 

Whatever you do, do not throw out the code!  Joel has an article on how unproductive throwing away your code is.  All that being said, I am not away of a refactoring tool that performs this function.  That doesn't mean there isn't one though. 

Joshua Volz Send private email
Tuesday, July 12, 2005
Yeah, we are trying to find a way to avoid doing it the "arcane" way. Thanks for the advice about not rewriting - I've already learned that, the hard way. (-;

The change is something like this:
StaticClass.Method(arg1, arg2);
newarg = LoadAnotherValue();
InstanceClass ic = new InstanceClass(newarg);
ic.Method(arg1, arg2);

Writing a custom "refactorer" might work - thanks!
Tuesday, July 12, 2005
Seems to me that you could do this pretty easily with regular expressions.
Kyralessa Send private email
Tuesday, July 12, 2005
Why not just find & replace "StaticClass" with "ic" across all files?  Then try to compile.  This'll list all the non-declared ic usages so you can go back and decide whether to make it a local or class variable and so you can add the new "LoadAnotherValue" code (which no automated refactoring tool is obviously going to know how to do anyway).
SomeBody Send private email
Tuesday, July 12, 2005
+1 for regular expressions combined with find and replace.

I've used it with lots of success on my VB6 to VB.NET conversion projects.

There are pitfalls to it, but following procedure helps to prevent problems:

1) Do a find all FIRST on your expression, then review the list found. This list will show any lines that shouldn't be changed. edit and redo until only the desired lines show up.

2) Find a single file with some good test cases and try find+replace on a line-by-line basis.
This usually means F+R->examine mistakes-> undo -> rewrite -> F+R->...

3) Once you're happy with the result, do a find all, by project or by file and then review the results.

4) If there's a problem, undo and go back to step 2.

If you have more than 10 identical or similar lines to replace in different places then this process is more than worth it.
Roman (doesn't need no steenkin' refactoring tools ;) Send private email
Tuesday, July 19, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz