*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Java Code -- VB Philosophy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Java Code -- VB Philosophy" Watch "Java Code -- VB Philosophy" New topic
Author

Java Code -- VB Philosophy

Tom Purl
Ranch Hand

Joined: May 24, 2002
Posts: 104
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!


Tom Purl<br />SCJP 1.4
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Tom Purl
Ranch Hand

Joined: May 24, 2002
Posts: 104
Thanks Ilja! That's what I was looking for.
 
wood burning stoves
 
subject: Java Code -- VB Philosophy