Re: decustmomising
Roedy Green wrote:
The last few days I have been decustomising three of my projects.
Html static macros, a Xenu back end broken link checker, and a tool
for manipulating HTML tables.
Each started out an in-house one-day project and grew and grew, then
I realised the code would have general application. But the code
contains all manner of magic strings and constants. It is quite a bit
of mindless work to remove the mindprod-specific code, and make
everything configurable.
Apps have to be split into core and customised sections.
This a special kind of refactoring. I wonder if there are any special
tools to help, e.g. to move magic configuration constants to a class,
convert them to variables, compose code to set them with a Properties
file or a generate a little GUI to set and validate them.
Some of the refactoring tools in IntelliJ have been invaluable, but
there is still a lot of mindless bull work that might be automated.
So the questions:
1. What is the official name of this process?
I would call it generalizing.
2. What tools do you use to expedite it?
IntelliJ IDEA has good ways to convert magic values to constants,
methods, variables, parameters, or fields (Introduce *). Deciding on
which one of those introductions to use is an engineering decision, and
I don't see how a tool can help you with that. Then I use extract
super-class and/or extract interface. Pull-up and push-down too.
3. If there were special tool created to help, what might it do? how
might it work? What features would you like?
Hmm, Actually, a tool I *would* like, is one that would take two
classes, figure out what is semantically similar between them, and
factor that out into a common base class.
Another tool/feature would be the ability to "find common method
signatures", and suggest interfaces and hierarchies for those interfaces.
Something else that I've found is that sometimes a "method" that is
designed to be overridden should actually not be overridden, but the
behavior in it should be externalized (strategy pattern). For example,
before:
class A{public void myMethod(int x, double y) { /* base definition */ }}
class B extends A {public void myMethod(int x, double y) { /*...*/ }}
after:
interface MyMethodStrategy { void doMethod(int x, double y); }
class A {
MyMethodStrategy strategy = new NullStrategy();
public void myMethod(int x, double y) { strategy.doStrategy(x, y); }
}
I would call this feature "Introduce Strategy". It would give the
option of remove overridden methods, but create the appropriate
implementation and instantiation of a new strategy class (combining
duplicates as necessary).
Basically, what you should ask yourself is,
"Am I applying a process in a mechanical way?"
"Are all of my decisions non subjective, or are those decisions simple
enough to present a dialog to the tool user?"
"Is this process a structural change only (no semantics are changing)."
If you answer no to any of those, then you probably can't create a
useful tool to do what you want to do.
Hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>