Re: Understanding Object Usage

James Perkins skrev:

Thorbjørn,
As always you have great advice. The interface makes more sense to me now. I
basically knew what they did and I've used them in examples, but I failed to
see the use of them in a whole. I like the contract concept though. That
makes a lot of sense.

Thank you. You are most welcome :)

As far as the comments go. They make a lot of sense too. I was struggling on
the concept of creating too many objects vs. creating the objects needed.
And just an FYI I'm not really migrating anything, just trying to learn is
all.

No problem. All programs were small once.

In my experience you get the best results by considering what makes sense to group together. If you put stuff in the wrong class you have to jump through hoops to get things done, and you will eventually have to move them anyway.

I do have one last question I forgot to ask and that's when to call a class
a bean. For example I will use the Customer.class again. It contains an
Address.class which basically just has address lines, city, state, zip and
country and getters and setters for each. Should this be named AddressBean
and since the customer is just customer information with getters and setters
should it be CustomerBean?

The Bean concept has gone through a lot of turmoil since it was invented to provide a way to handle a class inside a GUI, and then twisted to provide Enterprise JavaBeans (which is actually quite a different story) and then in disgust reinvented as POJO's. I will suggest you do Plain Old Java Objects since it is not hard:

1) Let the class implement java.io.Serializable. This is important in some scenarios.

2) Let all fields be private (a field is a "global variable" in an object, not inside any method, and not static)

3) Create getX() and setX(x) for all fields that shall be accessible for others.

That's it.

3 can be done by right-clicking, choosing Source, choose Create Getters and Setters.

I would not suggest you include "Bean" in the class name, unless it is really, really important that it is a BEAN. It rarely is.


And you should always use getters if you can, instead of referring directly to fields, even in the same package or even class. The reason: You can override methods but you cannot override fields. This allows you to modify functionality at a later date by creating a subclass of an existing class and add a small modification in a method, which can be indispensable for hotfixes, plus a lot of other things.

Also, notice that Eclipse and WSDCi provide a formatter. Configure it to fit your coding style (or adapt the default) and use it often when editing. It is a great help when you have a lot of tedious code to make it readable for future maintainers :)

/Thorbjørn