Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java Code -- VB Philosophy

 
Tom Purl
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm writing a pretty basic program using Java, and I don't have very much experience. I'm trying to design the program properly, but most of my design experience comes from using VB and I would like to do this properly, in a *real* OO way for a change.
The program basically has "employee" and "dependent" data that I'm treating as objects. In my main class file where I will manipulate all of the other classes, I would like to be able to manipulate these classes very easily.
To do this in VB, I would first (of course) create the Employee and Dependent classes. Next, I would create an Employees and a Dependentss class. I would then, for example, have the Employees class handle all of the heavy lifting that would be needed to manipulate multiple Employee objects (like managing a stack or Vector or whatever). In my main class, I would only reference the Employees class and I would never instantiate an Employee class.
Clear as mud? Is this a common practice in Java, or do you usually handle all of the object instances in your "main" class? What would you recommend?
Thanks in advance for any help!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tom Purl:
To do this in VB, I would first (of course) create the Employee and Dependent classes. Next, I would create an Employees and a Dependentss class. I would then, for example, have the Employees class handle all of the heavy lifting that would be needed to manipulate multiple Employee objects (like managing a stack or Vector or whatever). In my main class, I would only reference the Employees class and I would never instantiate an Employee class.
Clear as mud? Is this a common practice in Java, or do you usually handle all of the object instances in your "main" class? What would you recommend?

In my experience, the best OO designs are the ones that don't have a "main class", but are consisting of a "net of collaborating objects". The only responsibility of the main method in such systems is to initiate the "socializing" between those objects.
Wether an object speaks to an Employee or to the collection of Employee's (can you find a better name than Employees - something that describes the rationale for grouping them?) would then mainly be decided by wether it needs to work with one or more Employee's. You *might* want to restrict *instanciation* of Employee's to one class, though.
Does that help?
 
Tom Purl
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ilja! That's what I was looking for.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic