Re: How to design a good object-oriented package structure?

tenxian wrote:


Advice number one - newsgroups are best for specific requests, or at least
guided ones. That is, give a bit of context for your approach, your
background, what you might or might not know about programming or Java so far,
what you think you might want to know, what you've studied so far, what
troubles you in your studies.

Two - In Usenet posts, repeat your subject in the body of the post. Don't
just leave it in the subject line.

Three - "object-oriented" is a buzzword (or buzz-phrase, perhaps). What it
means, really, is thinking about and modeling your problem domain as
more-or-less independent modules, each of which contains its own behavior.

<http://java.sun.com/docs/books/tutorial/java/concepts/index.html>

Let's work out point three in some detail.

The textbooks use canonical examples like shopping carts (in the eCommerce
sense), student registration, and the like. Lets take recipes, just because I
feel like creating my own example to help me understand what I'm telling you.

In object-oriented analysis (OOA), design (OOD) and programming (OOP), an
"object" is a thing, of course, but a thing that has attributes and behaviors.

So in a recipe system, what would be the fundamental object? Let's guess a
Recipe (capitalized to show that it's on the way to becoming a class, and
isn't just the ordinary real-world thing). Now we need to figure the
attributes and behaviors.

What does a recipe have? It has ingredients and a set of steps for combining
and cooking them. Lets model the ingredients as an attribute and the cooking
steps as behavior. (Yes, our Recipe will cook itself.)

Jumping ahead to the class definition, here's how such a thing might look in
Java (simplified):

package cookbook;
import java.util.ArrayList;
import java.util.List;

public class Recipe
{
   String name;
   String category; // entr?e, dessert, etc.
   List <FoodItem> ingredients = new ArrayList <FoodItem> ();
   public void prepareDish()
   {
     // details
   }
}

Well, ingredients have to be something, too. I called that something
"FoodItem", since I figured recipes comprise food items that are combined and
cooked. A FoodItem will have attributes like 'name', 'content', 'foodGroup'
and the like, and behaviors like 'spoil( int days )'.

As you tease apart your problem domain, you'll come up with a bunch of nouns
and verbs - things in the domain and what they do.

Object types will tend to clump into related types of thing. A type of a
thing in Java is a class or an interface; related classes and interfaces group
together in a namespace called a "package".

<http://java.sun.com/docs/books/tutorial/java/javaOO/index.html>
<http://java.sun.com/docs/books/tutorial/java/package/index.html>

If you have an Internet domain, real or imaginary, say "lewscanon.com", you
will start your package namespaces with that domain name inverted, top-level
part first, then dot, then the second level, then dot, then your specific
project name, then sub-package names that distinguish logically separated
parts of your code.

For example, in a 'chef' project, lewscanon.com might publish packages
'com.lewscanon.chef' for the fundamental project classes,
'com.lewscanon.chef.cookbook' for the recipes, 'com.lewscanon.chef.cookware'
for classes that describe the utensils, and so on.

Java "sub-packages" are not related to their apparent "parent" packages except
in our minds. There is no semantic connection in Java between, say,
'com.lewscanon.chef' and 'com.lewscanon.chef.cookbook'. They are convenient
boundaries between groups of classes and interfaces, is all.

That's a start. Read the referenced tutorial for more of a start.

--
Lew