Class hierarchy uncertainty

Thread view:

Yuriy_Ivanov - 18 Dec 2006 12:56 GMT

I'm having a bit of trouble working out a correct hierarchy for my Java
classes.

Let's say simply my program is for crate construction for customers. It
works out which type of crate (out of 6 possible types) would be best
based on what the customer has specified.

I have:

A Main class for an interface - customer input prompt (type of crate,
width length etc) and a print out of the best crate for the customer.

A crateType class for storing crate variables, a few method calls and
variable calculations (of which would be the best type).

I want to make one of my classes abstract and I aim to use an applet for
customer inputs to make it a more friendly interface.

So far this is my design:

http://img367.imageshack.us/img367/2821/classesti5.gif

(Not completed as I'm not sure where to put all the variables/methods
until my hierarchy is sorted.)

I made the Type class abstract and my main class is my interface.

As I'm not too familiar with applets, I read that you need to extend the
whatever class you're using for an applet with the Abstract class.

So I can't do 'public class Interface extends Applet' because I've already
got:

'public class Interface extends crateType'
and
'public abstract class crateType'

If I separate my main class from my interface class, would that work?

But then what would my main class do?

Any help would be appreciated.

I can state more information too.

Reply to this Message

Oliver Wong - 19 Dec 2006 21:15 GMT

> I'm having a bit of trouble working out a correct hierarchy for my Java
> classes.
>
> Let's say simply my program is for crate construction for customers. It
> works out which type of crate (out of 6 possible types) would be best
> based on what the customer has specified.

It might help if you could explain what it is that makes the 6 types of
crates different.

> I have:
>
> A Main class for an interface - customer input prompt (type of crate,
> width length etc) and a print out of the best crate for the customer.

"interface" is a keyword in Java and has a very specific meaning in
object oriented design, so perhaps it's better if you don't name your main
class that. Perhaps you could name it "Main" intstead of "Interface".

> A crateType class for storing crate variables, a few method calls and
> variable calculations (of which would be the best type).
[quoted text clipped - 24 lines]
>
> But then what would my main class do?

Have your main class extend Applet, and not extend crateType. And try to
have your class names start with an uppercase letter (e.g. "CrateType"
instead of "crateType"). And if instances of your class describe a crate,
rather than describing a type of crate, consider calling it "Crate" rather
than "CrateType".

Read a tutorial on developing applets at
http://java.sun.com/docs/books/tutorial/deployment/applet/index.html

- Oliver

Reply to this Message

Yuriy_Ivanov - 20 Dec 2006 13:40 GMT

>Have your main class extend Applet, and not extend crateType. And try
>to
>have your class names start with an uppercase letter (e.g. "CrateType"
>instead of "crateType"). And if instances of your class describe a crate,

>rather than describing a type of crate, consider calling it "Crate" rather
>
>than "CrateType".
>
> Read a tutorial on developing applets at
>http://java.sun.com/docs/books/tutorial/deployment/applet/index.html

Okay, thanks, I'll try and explain a bit more about the problems since
I've tried to improve the design (or at least what each class should do).

My attributes will be what the customer specifies.
For example: length, width, color, grade of material, quantity etc of
crate.

I'll explain what each class will do, then explain what I what the program
should to do and finally touch on the problems.

Interface class
-Prompt input using label and textbox etc
-Validate inputs
-Handle I/O exceptions

Type 1 Type 2 Type 3 Type 4 Type5 Type classes
-Store attributes for pipe types
-(Constructors)
-(Access methods)
-(Update methods)
-Volume calculation method
-Cost calculation method

Main class
-Determine crate types
-Create type objects based on what was determined
=====================

Here's a mock example of how I want it to work:

A user uses the separate interface class (an Applet) to type in the values
of the attributes.
Text boxes/checkboxes will collect the information.
The interface class will also validate and prompt for re-input if the user
got it wrong.

Once input is collected, the program will determine which type of crate
this was, using the main class. Example: if crate is of grade 1 and has 2
colors,
then it will be Type1.

And once the crate type is found, an object can be made of the correct
Type class from the main class, the cost method will be called to
calculate what
this type will cost and then the final cost (of quanity) will be output on
the applet.

Problem 1: Type classes will have repeated methods accross hierarchy.
Problem 2: It will cause problems if I try to use too many If statements
in main, what can I do instead?
Problem3: Something isn't right about where the values will be stored, can
they be taken from the type classes and used to collect inputs on the
interface applet?
Once values are collected from the user, the attributes need to use the
methods to calculate volume and cost and output the info to the user.

I know mostly what I'm trying to achieve, it's just getting the
connections to each class and their type (Abstract, superclass etc)
right.

I hope I've explained enough, I've really tried to get this working the
way I want it to so hopefully someone can help with suggestions on what I
can add.

Thanks for any help.

Reply to this Message

Oliver Wong - 20 Dec 2006 14:52 GMT

> Type 1 Type 2 Type 3 Type 4 Type5 Type classes
> -Store attributes for pipe types
[quoted text clipped - 3 lines]
> -Volume calculation method
> -Cost calculation method

My main concern with regards to your design is that it's not clear why
you have six different classes, instead of a single class. Compare these two
designs:

<design1>
abstract class Box {
public abstract boolean isRed();
}

class RedBox extends Box {
public boolean isRed() {
return true;
}
}

class NotRedBox extends Box {
public boolean isRed() {
return false;
}
}
</design1>

<design2>
class Box {
private boolean isRed;

public boolean isRed() {
return this.isRed;
}
}
</design2>

Your current design looks like design1, and I'm wondering why it
couldn't be made to look like design2 instead.

- Oliver

Reply to this Message

Yuriy_Ivanov - 20 Dec 2006 16:18 GMT

> Your current design looks like design1, and I'm >wondering why it
>couldn't be made to look like design2 instead.

Well you see using 6 types was a way of distinguishing between them, but
since merging them into one with my first design, I'm not really sure how
I could distinguish between types.

I should explain I've not really needed to use more than one class in my
programs before, creating hierarchies is new to me and tutorials can only
take me so far without live examples.

I've had a go at how I think this could work:

<design2>
class CrateType {
private boolean isCrateType1;

public boolean isCrateType1() {
return this.isCrateType1;
}
}
</design2>

So if the user specified Type1 then I could call this method from within
the main class in order to show the user on the interface?

Would it help if I combine my main class and interface classes?

Reply to this Message

Oliver Wong - 20 Dec 2006 17:48 GMT

>> Your current design looks like design1, and I'm >wondering why it
>>couldn't be made to look like design2 instead.
[quoted text clipped - 21 lines]
> So if the user specified Type1 then I could call this method from within
> the main class in order to show the user on the interface?

Previously, you said the user specified length, colour, etc., and
depending on what they specified, you could determine a type of crate. Now
you're saying the user specifies the type of crate directly. Which is it?
The design will differ greatly depending on the answer.

> Would it help if I combine my main class and interface classes?

I don't think it would make a difference in terms of the class hierarchy
design issues mentioned above.

- Oliver

Reply to this Message

Ian Wilson - 20 Dec 2006 17:09 GMT

> I'm having a bit of trouble working out a correct hierarchy for my Java
> classes.

I don't think there is a single "correct" design for any given application.

> Let's say simply my program is for crate construction for customers. It
> works out which type of crate (out of 6 possible types) would be best
[quoted text clipped - 7 lines]
> A crateType class for storing crate variables, a few method calls and
> variable calculations (of which would be the best type).

Class names should start with a capital letter.

Any program I write that deals with crates is going to have a class
named "Crate" in it.

> I want to make one of my classes abstract

How about
abstract class Crate { ... };

Then you could have classes like
class RoundTin extends Crate { ... }
class WoodenBox extends Crate { ... }
class PaddedEnvelope extends Crate { ... }

You don't need subclasses unless your Crate class cannot accomodate all
the variations through simple attributes (e.g. field values). Having
different algorithms for one type of crate might be a reason for
subclassing Crate and overriding one or more of its methods.

> and I aim to use an applet for
> customer inputs to make it a more friendly interface.

Usual advice is to get it working as a desktop application first (unless
you have lots of experience with applets already).

> So far this is my design:
>
[quoted text clipped - 4 lines]
>
> I made the Type class abstract and my main class is my interface.

I think your class names are uncomfortably generic.

> As I'm not too familiar with applets,

Then don't start with an Applet.

> I read that you need to extend the
> whatever class you're using for an applet

Yes, every applet has a class that 'extends Applet'.

> with the Abstract class.

I can't work out what you mean by that in context.

> So I can't do 'public class Interface extends Applet' because I've already
> got:

This is multiple inheritance.
Ironically, Java has a concept named "interface" for handling this
situation. You would probably gain a lot from reading about Java's
inheritance, composition and interfaces.

> 'public class Interface extends crateType'

Most advice is to keep user-interface classes separate from classes that
are concerned with business data objects.

Oliver is right about the inadvisability of using Java keywords as class
names. I'd call it something like CratePanel (because I'd have it extend
JPanel).

> and 'public abstract class crateType'

I'd call it Crate or AbstractCrate.

> If I separate my main class from my interface class, would that work?

Yes.

> But then what would my main class do?

Load preferences, read command-line options, set the look and feel,
start a separate thread for the user-interface, instantiate a JFrame to
hold the GUI, etc. I see nothing wrong with having a trivial Main class
that does nothing but instantiate another class. It leaves room for
adding any of the above, for having a command-line (non GUI) version, etc.

> Any help would be appreciated.

Based on what you've said later in the thread, you might want to look at
some "Design Patterns" for Java. I find them a bit intimidating but you
might get some helpful clues from some, such as ...

http://en.wikipedia.org/wiki/Builder_pattern

If you are just starting with Java I'd start with something simpler than
the Builder Pattern. I'd have many small classes though.

Reply to this Message

Yuriy_Ivanov - 21 Dec 2006 17:05 GMT

Thank you for the suggestions.

>You don't need subclasses unless your Crate class cannot accomodate all
>the variations through simple attributes (e.g. field values).

The cost and volume calculation methods needed will be the same.
The separate classes represent the fixed types of crate, so they would
have to contain attributes for each type of crate with fixed variables.
For example Crate type 1 has: 2 colors, it does not have any metal
reinforcement and the grade of it is type 2 etc.

Once my main class uses the interface class to determine which crate they
chose, the information is used from the Crate classes to find a match.
Then the cost and volume calculations need to work on the type variables
from whichever class crate type was chosen.
The user is then notified of the price of however many crates they
specified that they wanted.

In theory it seems OK if I choose to extend a CrateType abstract class
using different Crate Type classes with their own set attributes. It's
just getting the connections to each class working I have problems with.

Since I already started developing with an applet, I thought I'd see how
far I could get with it. It all worked fine until I introduced exception
handling.

I have done so far:
..

public class CrateInterface extends Applet implements ActionListener {

//labels, text fields and check boxes declared here

//init method declared. Adds the components on the applet and adds
ActionListener to the text fields.

//public void actionPerformed(ActionEvent e) some code to set all fields
to blank

The problem is where I put my try catch statements for whatever is entered
into the text boxes and check boxes.

Because the main method is static, I can't use the variable names for the
components on the applet to handle the exceptions.

I'm sticking to compulsory rules here like I/O exceptions must be handled
in the user interface class.

Which is why if I could be totally flexible with the project, I'd try to
make it simpler with the design.

And otherwise, I'd simply ask the user which type of crate they'd like
after printing out the types in a list using one class and applet...

Reply to this Message

Class hierarchy uncertainty

Free Magazines