Re: Understanding Object Usage

James Perkins skrev:

Hello All,
This might not be the best place to post this, but since at least some of
you probably come from a procedural programming background you might be able
to help me understand this.

I have been working with Java for a little while now and I'm starting to use
it more and more. I have a slight disconnect when it comes to understanding
a few things.
1. When to create an Object? (e.g. a Customer.class would probably have a
Address.class)
2. When to use an interface over just using a class?

An interface is a _contract_. The implementation guarantees to have what the interface says, and the code in which it is used is guaranteed that the object is "in order" and can be used without checking all kinds of things.
A good example is "Comparable" (http://java.sun.com/j2se/1.3/docs/api/java/lang/Comparable.html) where the sole method in the interface is:

public int compareTo(Object o)

If a class implements Comparable it MUST contain the compareTo method, and if a result from a method is declared to be of type Comparable (i.e. the interface, and not a class) you only know that it is guaranteed to have a compareTo method which you can then call without further adeu if the object is non-null.

Hence it is a way of hiding unneccesary detail. It is highly recommended to use interfaces where it makes sense - i.e. where you have a CONTRACT between different parts of your code.

Take for example a customer order. A normal customer order would consist of
a header and a detail.
So, would you create a header class and a detail class, then an order class
that consists of a header and an array of detail? Or do you just create an
order class that would have header information and detail arrays?

I would probably consider such an order to contain fields for header information, and a list of OrderItems for the items in the order.

Usually the criteria is "does this make sense on its own" - if not, then don't create a class for it. If it makes sense on its own, then you should still think "do I _need_ it in its own class"?

There is a lot of typing to do to get all this working, and if all you need to do is to move some information from some internal API to a web frontend, then you may actually benefit from creating maps of string->string / string->maps instead of a rich class hierarchy. The benefit here is that you can quickly create a loose data structure which can be refactored without having to tear down a lot of code.


/Thorbjørn