When to create an object...

[dav mccartney]

For my Java course, I have to implement a solution using polymorphism and interitance. I have a pretty solid idea of what I want to do, and how to do it, but I'm not sure what the best way to implement it is b/c of certain conditions.
We're creating a vote processing system, and there are now multiple types of votes. Depending on which vote type of vote is being read, a certain object will have to be created: either a SimpleVote, a MajorityVote, or a QuorumVote. I plan to have Simple and Majority votes extend an abstract class, and then have QuorumVote extend MajorityVote (all of this makes sense in the scope of the assignment).
Here is my dilemna: To know which type of object to create, I have to tokenize a particular string. Previously, I would pass the untokenizied string as an argument, because there was only one type of vote. Now, I need to tokenize the string, see which type of vote it should be based upon the tokenized data, and then create the correct type of object.
Would it be better to pass the string into the abstract class, then create the object based on the data presented? Or, should I just try to tokenize the string elsewhere, like a method in main where I read the line, and use a Switch or if/then statement to create the object?
Does my question, and explanation make sense? I can provide further info, just ask
Thanks!
dav

[Howard Kushner]

Consider creating another class that would be responsible for parsing the string and creating the proper type of vote. I might call the new class something like VoteFactory, and it would have a method like createVote that would take the string as a parameter and return a vote object. Make sense?

[dav mccartney]

Thanks for the response, Howard.
When I create and return the object, would I 1) already have assigned the tokenized values to the returned object? (can I, even?) Or, 2) should I tokenize, determine object type, create and return a blank object, then pass the blank object the string and tokenize, assign, and go from there (which sounds like a ton of extra work the more I type about it and probably is a no...)
For example of 1): I pass a string into VoteFactory. VoteFactory determines that a SimpleVote should be created. SimpleVotes only have 3 properties... so would I (in pseudocode...)
Tokenize Line
Determine Object Type
if object is a SimpleVote then
(abstractunnamed class) v = new SimpleVote
v.1stproperty = blah
v.2ndprop = bleh
v.3rdprop = woot
return v
if object is NextType... etc. etc.

[Howard Kushner]

I see the solution kind of like this.
Let's say we have a class Vote that's our abstract base class. The we have the subclasses SimpleVote, MajorityVote, and QuorumVote as you stated earlier.
I would code VoteFactory like this:

public class VoteFactory {
    public static Vote createVote(String toBeTokenized) {
        // determine the type of vote to create
        // create the appropriate vote type
        // return the newly created vote object
}

I would invoke the factory method like this:

Vote v1 = VoteFactory.createVote(stringToTokenize);

Hope this helps.
[ February 28, 2004: Message edited by: Howard Kushner ]

[sever oon]

Another thing you might want to consider...it might simplify your code with no adverse effects if you make createVote() a static method in Vote (abstract base class). Sort of the same approach used by the parse methods of the wrapper classes in the JDK (java.lang.Integer, java.lang.Double, etc):

public abstract class Vote {
  public static Vote createVote( String voteString ) {
    // tokenize and determine which subclass to create
  }
  // ...
}

As long as you create appropriate constructors for all the subclasses of Vote, you can initialize them with the String tokens that you've parsed any way you want:

public class SimpleVote extends Vote {
  public Vote( String token1, String token2 ) {
    // initialize a simple vote instance with provided tokens....
  }
  // ...
}

To use this code:

String simpleVoteString = "simple vote";
Vote simpleVote = Vote.createVote( simpleVoteString );

As the this example code indicates, you could cast simpleVote to type SimpleVote if you needed to--though, if you are truly dealing with all these different subclasses polymorphically, you shouldn't need to downcast them or use ugly instanceof checks.
sev

[Stan James]

A couple notes: This whole factory notion is a good one. It nicely hides the details of mapping the string vote type to a class. This is especially good if you might be creating votes from lots of places because it avoids duplicating those details in every place. While it's a great lesson, don't take it to mean you should make a factory every time you have to create some polymorphic objects. Sometimes it is just more overhead and complixity.
Second, using the base class as a factory for derived classes may have a place in a closed package. Studying dependencies may be a bit advanced right now, but lemme just say that making the abstract class know about derived classes (as it must to do that mapping of vote type to class) is a little like fingernails on the chalkboard. If that made sense, speak up and we can talk about it more. If it just whizzed by, don't worry about it yet.

[Dirk Schreckmann]

Moving this to the OO, UML, Patterns and Refactoring forum...

[sever oon]

Stan makes a good point, and one I should have been more clear about...you generally do not want a superclass to know about subclasses, because then any time you want to compile that base class you must have access to all of the subclasses. If your aim is to write truly extensible classes that other developers can extend, better to follow the guideline Stan is referring to.
However, if you have a good reason that you do NOT want your classes extended by subclasses outside your package, then make sure the constructor for the Vote class is marked package-private, and you can follow my suggestion of putting in the static createVote() method. (If the Vote constructor(s) is marked package-private, the class as a whole can still be marked coderanch, but all subclasses will have to belong to the same package because all subclasses always require access to their parent's constructor.)
If you're interested in learning more about this dependency stuff, check out this article on the Dependency Inversion Principle over at Object Mentor. There are a lot of good articles in their resources section, definitely worth a browse.
sev

[dav mccartney]

Thanks for the input, all.
It's getting a bit above my head, but I'm going to try and chew on it some and figure out how to best implement the suggestions based on my knowledge. Seems the instructor is tweaking the lab a bit, so it's hard to tell where that will take it
I appreciate your time, and have bookmarked this for reading as I progress in knowledge
dav