× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Hi James:

1. When to create an Object? (e.g. a Customer.class would probably
have a
Address.class)

If the address may be used in some other way or has some independence
from the Customer.class then break it out into an Address.class. If the
address information would only be used as part of a Customer then make
the address information instance variables of Customer.

One way to think about it is when would you break out the address
information into a separate record and include a key to the Address
record in a Customer record?

2. When to use an interface over just using a class?

An interface just lists the methods which a class must have in order to
implement the interface and any constants. There is no code or data in
an interface. It is a guide for creating classes. You can create an
interface and start using it, then later flesh it out into classes.

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?

The header class would probably have a customer class, which probably
has an
address class.
Now would have an item number, description, quantity ordered, quantity
shipped, and price. But would the item number be better as an
ItemNumber.class that contains the description?

Basically, I'm just looking for where do you draw the line in creating
objects?

I'd draw the line at the place where I see any point in treating the
data as a group.

I'd create separate header and order classes only if they could be used
differently and independently. I can't think of a good reason to off
the top of my head so I probably wouldn't -- at least not until I got
further into the project and found out why I needed to separate them.
So I would create an order class that referenced a Customer.class with a
Collection of Detail.classes.

The ItemNumber.class would consist of
Item number
Description
Quantity on hand
My cost

The Detail.class would consist of
ItemNumber.class
BigDecimal price
int quantityOrdered
int quantityShipped

The Order.class would consist of
Order header fields
Customer.Class
Collection of Detail.class

That is my opinion.

Basically, I'm just looking for where do you draw the line in creating
objects?

Assuming you are an i5 professional, where would you draw the line at
normalizing a database design? It is a similar thought process.

Don't be afraid to refactor. Most of the time you won't get the design
right the first time. Going back and fixing it is just part of the
development process.

One point the books don't address is persistence. Somehow you are going
to have to store and retrieve your orders, customers, details, addresses
etc.

That means reading a data source and converting the data into objects.
So I keep that in mind when I am designing classes.

Bill
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Perkins
Sent: Tuesday, October 21, 2008 2:40 PM
To: Java Programming on and around the iSeries / AS400
Subject: Understanding Object Usage

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?

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?

The header class would probably have a customer class, which probably
has an
address class.
Now would have an item number, description, quantity ordered, quantity
shipped, and price. But would the item number be better as an
ItemNumber.class that contains the description?

Basically, I'm just looking for where do you draw the line in creating
objects?

I have read several books, but all the examples are usually pretty small
and
don't really seem to go too deep into this kind of stuff. So any links
to
good articles, books, or just advice in general would be appreciated.

--
James R. Perkins

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.