• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Abstract class with main method

 
Bennett Rainville
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Bennett Rainville
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic