• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

When to create an object...

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:

I would invoke the factory method like this:

Hope this helps.
[ February 28, 2004: Message edited by: Howard Kushner ]
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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):

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:

To use this code:

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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving this to the OO, UML, Patterns and Refactoring forum...
 
sever oon
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 public, 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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic