This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am attempting to write a series of java classes, each of which will be executed from the command line. Each of these classes will have some shared functionality, and I am thinking of using an abstract class to hold this. However, I am doing something that seems to be pretty dumb, and I'm wondering if there is a better way of doing what I want to do. Here's a simplified version of my code:
As I would expect, if I run the main method on SubClassA with SubClassA as a paremeter, it prints out "In setup", "In SubClassA", and "In finish". However, there's got to be a way where I can get rid of the need to pass in this parameter, and in doing so remove the ugly Class.forName on line 1 of the main method. Any ideas?
I like your interest in pluggable implementations. One way to approach ugly code is to move it into another class and forget about it. Seriously, you can move object creation to some kind of creational helper (avoiding the word Factory which has a specific meaning that I don't want to get into).
That isolates your logic from any creation issues, such as exceptions. You don't have to know if the Vendor (it's hard to make up new words that don't already have meaning here) uses Class.forName() or looks up the classname by a logical key, makes new instances every time or gives you existing instances from a pool.
I'd look to break your program up a bit, move main() to a new class that sets up some configuration, like which subclass to use. We could maybe make that Vendor fit the Factory Method pattern.
Any of that sound useful? [ May 16, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Feb 16, 2007
That's a good suggestion. I'll add something like that.
What I'd really like, though, is to move completely away from the Class.forName, with something like this:
Doing something like this would eliminate the need for the Class.forName in the main method. Note that the getInstance method must be static for it to be accessed in the main method. However, a method cannot be both static and abstract, so my getInstance() idea won't work as it is written. I have also experimented with making it not abstract (only static), and overriding it in SubClassA. However, even though I'm running main() on SubClassA, and SubClassA has a getInstance method, the getInstance method in SuperClass is being executed, not the one in SubClassA (in fact, I'm not even sure you can override static methods). Any thoughts? [ May 17, 2007: Message edited by: Bennett Rainville ]
How about this, I removed the Class.forName(String) using Enum.valueOf. The only catch here is that the enum type must know about all subclasses at compile time (that means its nowhere near as flexible as Class.forName()), then you pick the appropriate enum at runtime. Doesn't make anything prettier or more elegant though, quite the contrary. But it was fun seeing if it would work.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com