Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / First Aid / February 2007

Tip: Looking for answers? Try searching our database.

classes and inheritance revisited

Thread view: 
John T - 15 Feb 2007 02:00 GMT
After all the discussion about the last set of questions I posted, I
decided to proceed with a simpler version of the Animal class hierarchy.
Everything is in one package (main..bad name but it works).
I have an Animal (hey RedGritty...I made those changes...still not quite
what I want)

package main;

public class Animal {
    private String type;
    private char gender;
    private int numberOfLegs;
    private char warmOrCold;
    private char birthType;
    private char eatType;
    public Animal(String type, char gender, int numberOfLegs, char
warmOrCold, char birthType, char eatType) {
    super();
    this.type = type;
    this.gender = gender;
    this.numberOfLegs = numberOfLegs;
    this.warmOrCold = warmOrCold;
    this.birthType = birthType;
    this.eatType = eatType;
    }
    void move() {}
    void sleep(){}
    void giveBirth() {}
    void eat() {}
    public char getBirthType() {
    return birthType;
    }
    public void setBirthType(char birthType) {
    this.birthType = birthType;
    }
    public char getEatType() {
    return eatType;
    }
    public void setEatType(char eatType) {
    this.eatType = eatType;
    }
    public char getGender() {
    return gender;
    }
    public void setGender(char gender) {
    this.gender = gender;
    }
    public int getNumberOfLegs() {
    return numberOfLegs;
    }
    public void setNumberOfLegs(int numberOfLegs) {
    this.numberOfLegs = numberOfLegs;
    }
    public String getType() {
    return type;
    }
    public void setType(String type) {
    this.type = type;
    }
    public char getWarmOrCold() {
    return warmOrCold;
    }
    public void setWarmOrCold(char warmOrCold) {
    this.warmOrCold = warmOrCold;
    }
    void showAll() {
    System.out.println("type:  " + type );
    System.out.println("gender:  " + gender);
    System.out.println("numberOfLegs:  " + numberOfLegs);
    System.out.println("warmOrCold:  " + warmOrCold );
    System.out.println("birthType:  " + birthType );
    System.out.println("eatType:  " + eatType );
    }
}

Here is a Cat

package main;

public class Cat extends Animal {

    public Cat(String type, char gender, int numberOfLegs, char warmOrCold,
       char birthType, char eatType) {
    super(type, gender, numberOfLegs, warmOrCold, birthType, eatType);
    }

}

Here is a HouseCat

package main;

public class HouseCat extends Cat {
    String catName;
    public HouseCat(String houseCatName, String type, char gender, int
numberOfLegs, char warmOrCold, char birthType, char eatType) {
       
        super(type, gender, numberOfLegs, warmOrCold, birthType, eatType);
        // TODO Auto-generated constructor stub
        this.catName = houseCatName;
    }
   
    void move() {
        System.out.println("pounce");
    }
    void eat() {
        System.out.println("yummy");
    }
    void showAll() {
        super.showAll();
        System.out.println("Name:  " + catName);
    }
}

And here is my HouseCatTest

package main;

public class HouseCatTest {
    public static void main(String[] args) {
    HouseCat hc = new HouseCat("Sparkles", "tabby", 'm', 4, 'w', 'l', 'c');
    hc.showAll();
    }
}

Output:

type: tabby
gender: m
numberOfLegs: 4
warmOrCold: w
birthType: l
eatType: c
Name: Sparkles

Which is exactly what I wanted.

See the thing is: I see Animal as more of an Interface that is
implemented by Cat than as a Class. But an Interface has no instance
variables so how can I make Animal an interface? That would mean that
the instance variable of Animal would have to be contained in the
classes that implement the interface. Can you say, "code duplication"?
Is there an alternative or a better way to work this together.
Here's my image

An animal knows about:
 type :  What kind of animal is it
 gender : mALE or fEMALE
 numberOfLegs : 0, 2, 4 whatever
 warmOrCold : wARMBLOODED or cOLDBLOODED
 birthType : lIVE or eGGS
 eatType : cARNIVOR, oMNIVORE, hERBIVORE

and probably a bunch more

An animal knows how to:
 move
 sleep
 giveBirth
 eat

and probably a bunch more

A cat knows about everything that an Animal knows about (a cat IS-A animal)

But a Cat also knows about:

itsTail : some Animals don't have one so this instance variable needs to
be in cat
breed: breaking down Animal further

and it knows how to:
huntInPacks
makeNoise (not all Animals make audible noises)

A HouseCat knows about everything that a Cat knows about (a housecat
IS-A cat)

But a HouseCat also knows about:
itsName: you give your pets names don't you?

and knows how to
chaseAMouse

So to me, Animal in an interface.
Cat is an interface that implements Animal (but an interface can't and
implement an interface, at least that's what Eclipse is saying)
And HouseCat should both extend and implement Cat, but I can't do that
either.  This is getting frustrating...what am I missing.
K Gaur - 15 Feb 2007 02:13 GMT
have u heard about abstract classes
if u have do a bit of reading on that and things will unfold into a
better picture
John - 15 Feb 2007 03:04 GMT
> have u heard about abstract classes
> if u have do a bit of reading on that and things will unfold into a
> better picture

I've read up on them, but I don't see how they can fit into my design,
yet!!!  Thanks for the clue.
rbarua@bulkpetro.com - 16 Feb 2007 22:15 GMT
> have u heard about abstract classes
> if u have do a bit of reading on that and things will unfold into a
> better picture

hi...this is mickey(harsimrat thukral)  ..have u ever read the
horton's java coz somebody told me its better but not available in
market nowadays ...
N one thing more...wt bout combination of doing jsp,ejb ,struts
and ..?   wt IDE should i choose to develop like eclipse or Ajax or
anyother one ...??
r u a professional one ?
Lew - 16 Feb 2007 22:55 GMT
>  r u a professional one ?

I do not understand what you are trying to ask. I assume that "r u" stands for
"Are you", but "professional one" what?

Take the extra effort to use complete English and to explain what you're
asking about. That way someone can hope to answer your question.

- Lew
Patricia Shanahan - 15 Feb 2007 03:10 GMT
...

> So to me, Animal in an interface.
> Cat is an interface that implements Animal (but an interface can't and
> implement an interface, at least that's what Eclipse is saying)
> And HouseCat should both extend and implement Cat, but I can't do that
> either.  This is getting frustrating...what am I missing.

A Java "interface" cannot implement anything, but one interface can
extend another.

However, at some point you do have to supply some implementation, and
that must be in a class.

Patricia
Hendrik Maryns - 15 Feb 2007 12:10 GMT
John T schreef:
> After all the discussion about the last set of questions I posted, I
> decided to proceed with a simpler version of the Animal class hierarchy.
> Everything is in one package (main..bad name but it works).
> I have an Animal (hey RedGritty...I made those changes...still not quite
> what I want)

Indeed.  I gave some comments:

> package main;

How about package animals?

> public class Animal {

It would help very much if you included some comments about what all
these variables represent.  The names are good, but not enough.

>     private String type;

This is superfluous: the class defines the type of animal.  A Cat does
not have to store a string saying it is a cat, since it is, well, a Cat.

>     private char gender;

Why not boolean?  (Ok, snails and stuff, then use an enum, see below)

>     private int numberOfLegs;
>     private char warmOrCold;

But this really should be a boolean.  Don’t try to encode stuff in
strange letters.  People (maybe only you, but still) have to remember
what letter stands for what, and it gives room for inconsistency (what
if someone set it to 'z'?

>     private char birthType;

Same comment.  But here, a boolean is not appropriate.  Instead, have a
look at enums (since Java 5): enum BirthType { EGG, LIVE, CELL_SPLIT }

>     private char eatType;

Idem, use an enum.

>     public Animal(String type, char gender, int numberOfLegs, char
> warmOrCold, char birthType, char eatType) {
[quoted text clipped - 6 lines]
>     this.eatType = eatType;
>     }

>     void move() {}
>     void sleep(){}
>     void giveBirth() {}
>     void eat() {}

Those 4 should be abstract (see below).

>     public char getBirthType() {
>     return birthType;
>     }
>     public void setBirthType(char birthType) {
>     this.birthType = birthType;
>     }

Are you sure you want people to be able to set the birth type for any
animal?  I suppose a cat gives live birth, so you do not want to let
people make it lay eggs.  Since birth type is predestined, this variable
should be set only once.  I.e. you want it to be a final variable, and
remove the setter.  Same for all four below.

>     public char getEatType() {
>     return eatType;
[quoted text clipped - 26 lines]
>     this.warmOrCold = warmOrCold;
>     }

>     void showAll() {
>     System.out.println("type:  " + type );
[quoted text clipped - 16 lines]
>     super(type, gender, numberOfLegs, warmOrCold, birthType, eatType);
>     }

I don’t think you need numberOfLegs, warmOrCold, birthType and eatType
in the constructor.  They are predestined for cats.  So, supposing you
have a public enum Gender{MALE, FEMALE, ANDROGYNOUS} (remember I  threw
out type):

 public Cat(Gender gender) {
   super(gender, 4, WARM, LIVE, CARNIVOROUS);
 }

> }
>
[quoted text clipped - 11 lines]
>         this.catName = houseCatName;
>     }

Since Cat only asks for a gender, you’ll have to adapt this constructor too:

 public HouseCat(String name, Gender gender) {
   super(gender);
   this.catName = name;
 }
>    
>     void move() {
[quoted text clipped - 16 lines]
>     public static void main(String[] args) {
>     HouseCat hc = new HouseCat("Sparkles", "tabby", 'm', 4, 'w', 'l', 'c');

 HouseCat hc = new HouseCat("Sparkles", MALE);

>     hc.showAll();
>     }
[quoted text clipped - 18 lines]
> classes that implement the interface. Can you say, "code duplication"?
> Is there an alternative or a better way to work this together.

Indeed, you need an abstract class and interfaces.  As Patricia said,
interfaces are nice, but you have to put the methods somewhere.  And
indeed, you don’t want code duplication, so you try to pull them up in
you hierarchy as high as possible.  Animal is appropriate for (most of)
what you put in there, but you do not want people to instantiate some
Animal.  So you make it abstract, that way only subtypes of animal can
be instantiated.

> Here's my image
>
[quoted text clipped - 13 lines]
>  giveBirth
>  eat

Not all animals sleep or move.  So define interfaces Moving and
Sleeping, and have moving animals implement them.  You might want a
(still abstract) class Mammal between Animal and Cat, and have it
implement Moving and Sleeping, since all Mammals sleep and move, and
also make it warmblooded by default.  In Mammal, sleep() and move() will
also be abstract, such that they have to be implemented by all mammals.
But concrete mammals such as Cat will not have to think about whether
thay are warmblooded, since Mammal knows that.

> and probably a bunch more
>
[quoted text clipped - 4 lines]
> itsTail : some Animals don't have one so this instance variable needs to
> be in cat

As above: this might be appropriate in Mammal (but there are always
exceptions, such as Humans, arguably), or even some other class
TailedAnimal in between.  It all depends on how detailed you want to
make your application.

> breed: breaking down Animal further
>
> and it knows how to:
> huntInPacks
> makeNoise (not all Animals make audible noises)

This is also a candidate interface, which, I think, Mammal should
implement, but Fish not.

> A HouseCat knows about everything that a Cat knows about (a housecat
> IS-A cat)
[quoted text clipped - 4 lines]
> and knows how to
> chaseAMouse

I think all Cats know that.

> So to me, Animal in an interface.
> Cat is an interface that implements Animal (but an interface can't and
> implement an interface, at least that's what Eclipse is saying)

An interface can extend another interface.

> And HouseCat should both extend and implement Cat, but I can't do that
> either.  This is getting frustrating...what am I missing.

That you need some place to put the code, so it is impossible to have
only interfaces.  Interfaces are just a way to keep multiple inheritance
out of Java anyway.  Maybe you could forget about interfaces for a while
and think in classes which you keep as simple as possible, then look
where you have multiple inheritance, and make the less essential
ancestors interfaces.

HTH, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
John T - 15 Feb 2007 13:40 GMT
> That you need some place to put the code, so it is impossible to have
> only interfaces.  Interfaces are just a way to keep multiple inheritance
> out of Java anyway.  Maybe you could forget about interfaces for a while
> and think in classes which you keep as simple as possible, then look
> where you have multiple inheritance, and make the less essential
> ancestors interfaces.

You are correct.  I think I'm a bit too ambitious.  I need to start out with
the lowest classes, get them working first and then worry about inheritance,
encapsulation and abstract classses.  But one thing that you said made
really good sense (well not just one but..) the bit about abstract classes.
I think that both Animal and Cat would be abstract class candidates (did you
say that too).  From my limited understanding of abstract classes, they
exist so that they can't be instantiated.  Is this correct?  Seriously
though... if I have a whole bunch (there's that susinct word again) of
classes like:

houseCat
domesticDog
deer
moose
wolf
coyote
lion
tiger
bear (oh my)
snake

I will get these classes working to the point where I can create new
reference objects and have arrays and ArrayLists working.  Then I can take
it up one level.
Lew - 15 Feb 2007 14:59 GMT
> You are correct.  I think I'm a bit too ambitious.  I need to start out with
> the lowest classes, get them working first and then worry about inheritance,
> encapsulation and abstract classses.  

It usually makes more sense to take a roughly "top-down" approach, that is,
from the very beginning design your inheritance. You will probably have poorer
results starting at the "lowest classes". How would you even know what is
"lowest" unless you have a sense of the hierarchy?

The design or modeling phase of development is where you elicit the data
structures in your domain of discourse. If your analysis is sound, your class
design can mirror it without too very much difficulty.

> Seriously though...
> if I have a whole bunch (there's that susinct word again) of
[quoted text clipped - 10 lines]
> bear (oh my)
> snake

By nearly universal, Sun-recommended Java convention, class names begin with
an upper-case letter. If you follow that convention you will find it easier to
communicate source-code ideas.

> I will get these classes working to the point where I can create new
> reference objects and have arrays and ArrayLists working.  Then I can take
> it up one level.

Empty classes, without attributes or behaviors, are sufficient for that goal.

- Lew
John T - 15 Feb 2007 15:34 GMT
>> You are correct.  I think I'm a bit too ambitious.  I need to start out
>> with the lowest classes, get them working first and then worry about
[quoted text clipped - 35 lines]
>
> - Lew

Lew,

I have done some level of analysis, in various iterations, and I have
identified the classes above as those at the lowest level.  My plan is to
create detailed class instances of each of:

HouseCat
DomesticDog
Deer
Moose
Mouse
Wolf
Coyote
Lion
Tiger
Bear
Snake
Human

By detailed, I mean to have all the attributes and methods for each
initially included in the class code.  Once I have all my classes coded, I
can encapsulate what varies (a design principle) and move those attributes
and methods to a super class of some sort.
andrewmcdonagh - 15 Feb 2007 20:56 GMT
> >> You are correct.  I think I'm a bit too ambitious.  I need to start out
> >> with the lowest classes, get them working first and then worry about
[quoted text clipped - 59 lines]
> can encapsulate what varies (a design principle) and move those attributes
> and methods to a super class of some sort.

So reading this thread, it appears that you are starting to understand
the Java mechanics of class hieracharies (Interface, Abstract Classes
and Classes) which is a good start.  Some minor confusions or over
simplification maybe of certains aspects of these, but on the whole
you seem to have it now.  I'd say you could easy see how the following
works....

public interface Animal {
   void move();
   String getName();
}

public abstract class AbstractAnimal implements Animal {

  private String animalName;

  public AbstractAnimal(String name) {
     animalName = name;
  }

  public String getName() {
    return animalName;
  }
}

public class Cat extends AbstractAnimal {

  public Cat(String name) {
    super(name);
  }

  public void move() {
     System.out.println( getName() +  " moved!");
  }
}

public class Test {
   public void main(String[] args) {
      Animal moggy = new Cat("Moggy");
      moggy.move();
   }
}

Output:

Moggy moved!

However, I do think some of your confusion is coming from trying to
model the Animal kingdom using Inheritance....

Some aspects of it should not use inheritance but instead should be
Delegation (nice word for meaning, two class instances (objects)
working together - much like 'animalName' is a String and moggy is
Cat....)

So if we tried to model your set of animals using delegation and just
a shallow inheritance tree, what would it look like?

Andrew
Hendrik Maryns - 16 Feb 2007 12:22 GMT
John T schreef:
>> That you need some place to put the code, so it is impossible to have
>> only interfaces.  Interfaces are just a way to keep multiple inheritance
[quoted text clipped - 9 lines]
> I think that both Animal and Cat would be abstract class candidates (did you
> say that too).

I said that for Animal.  However, not every class which is not a bottom
class needs to be abstract.  For example, Cat can be concrete, such that
you can have general cats, and still subclass it for HouseCat, which has
some extra behaviour.

> From my limited understanding of abstract classes, they
> exist so that they can't be instantiated.  Is this correct?  

Yes, and at the same time provide implementations for common stuff
subclasses will use.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Patricia Shanahan - 15 Feb 2007 14:06 GMT
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John T schreef:
...
>> itsTail : some Animals don't have one so this instance variable needs to
>> be in cat
[quoted text clipped - 3 lines]
> TailedAnimal in between.  It all depends on how detailed you want to
> make your application.
...

Lizards have tails. Manx cats do not. I think John had this one right in
NOT making it part of the class hierarchy.

Patricia
Alex Hunsley - 15 Feb 2007 16:21 GMT
> After all the discussion about the last set of questions I posted, I
> decided to proceed with a simpler version of the Animal class hierarchy.
> Everything is in one package (main..bad name but it works).
> I have an Animal (hey RedGritty...I made those changes...still not quite
> what I want)

I would just like to chime in here to say some design decisions can be
made more easily if you have some sort of idea of how your class
hierarchy is going to be used in the end.

For the moment, it seems you're designing a hierarchy without much idea
yet of how these classes would be used. (Please forgive me if I've
missed somewhere where you gave an idea of how these classes might be
used!) To a certain degree, you can make up example scenarios, but
having some 'how will I be using these classes?' concept in mind can
help guide you.

lex
John T - 15 Feb 2007 16:37 GMT
>> After all the discussion about the last set of questions I posted, I
>> decided to proceed with a simpler version of the Animal class hierarchy.
[quoted text clipped - 13 lines]
>
> lex

This is an educational experience for me.  I am making my way through some
of the more popular books on Java Programming and am trying to put what I
learn into practice with real-world scenarios.  My initial thought was to
model the Animal Kingdom, but that proved a bit too ambitious.  Then I toyed
around with the idea of modelling a military structure.  But that proved to
difficult to nail down.  So I went back to my initial idea, but decided to
start out small, with a few classes which I had identifed as being at the
bottom of the hierarchy.
Oliver Wong - 15 Feb 2007 18:30 GMT
>> I would just like to chime in here to say some design decisions can be
>> made more easily if you have some sort of idea of how your class
[quoted text clipped - 16 lines]
> decided to start out small, with a few classes which I had identifed as
> being at the bottom of the hierarchy.

   If you're trying to model the animal kingdom, then I wouldn't have
classes like "Cat", "Tiger", "Deer", etc. because you wouldn't actually have
cats, tigers or deers in your model. Rather, you would have the concept of
the species called "cat", the species of the concept called "tiger", the
concept of the species called "deer" and so on.

   I.e. you're not modeling individual cats, but the concept of a cat
itself. Thus your classes might be Phylum, Order, Family, Genus, etc.

   Alternatively, maybe you *do* want to model a bunch of cats running
around and mewling. In which case, you're not modeling the animal kingdom,
but rather a bunch of cats (or other animals) doing whatever it is that
those animals do.

   Perhaps some of the confusion is arising because you haven't decided
which between these two alternatives you're going for.

   - Oliver
Patricia Shanahan - 15 Feb 2007 18:58 GMT
...
>     Perhaps some of the confusion is arising because you haven't decided
> which between these two alternatives you're going for.

The more I watch this thread, the more convinced I become that object
modeling in the total absence of even one use-case is doomed to confusion.

Patricia
John T - 15 Feb 2007 19:32 GMT
> ...
>>     Perhaps some of the confusion is arising because you haven't decided
[quoted text clipped - 4 lines]
>
> Patricia

What's the point of having a use case if what I am doing is not going to be
used for anything except my own curiousity and education?  Doesn't a
use-case have to do with customer requirements for a system that does
something?  Well this "system" does nothing, therefore it's useless to
anyone but me.  I have no requirements except to be able to practice what I
learn, but this seems hardly something which would require a use-case.
Maybe I'll just go away and read some more... I come here for clarification,
it is not my intention to cause confusion.
Patricia Shanahan - 15 Feb 2007 19:43 GMT
>> ...
>>>     Perhaps some of the confusion is arising because you haven't decided
[quoted text clipped - 6 lines]
> What's the point of having a use case if what I am doing is not going to be
> used for anything except my own curiousity and education?

It would give direction to your design effort. You would be able to
compare the effectiveness of different choices. You could write tests
based on the use-case, and see your code do something, not just sit there.

Patricia
John T - 15 Feb 2007 19:50 GMT
>>> ...
>>>>     Perhaps some of the confusion is arising because you haven't
[quoted text clipped - 13 lines]
>
> Patricia

I see where you are coming from with this.  Once I figure out the methods I
want to add, I'll come up with some use-cases.
Patricia Shanahan - 15 Feb 2007 20:03 GMT
>>>> ...
>>>>>     Perhaps some of the confusion is arising because you haven't
[quoted text clipped - 14 lines]
> I see where you are coming from with this.  Once I figure out the methods I
> want to add, I'll come up with some use-cases.

Remember you can always add or change a use-case. One of the tests of
good software engineering is what happens if you find out your program
has to deal with some unanticipated requirement.

Patricia
K Gaur - 17 Feb 2007 13:52 GMT
> Patricia
>
> I see where you are coming from with this.  Once I figure out the methods I
>  want to add, I'll come up with some use-cases.

would you please tell me what this use-case thing is? are you
referring to the swith-case selection statements?
please do update me on this subject

thanks
Lew - 17 Feb 2007 14:23 GMT
 > would you please tell me what this use-case thing is? are you
> referring to the swith-case selection statements?
> please do update me on this subject

A use csse is a formal description of one usage scenario for the application,
e.g., "user logs on to the system".

GIYF.

- Lew
MikeNereson - 17 Feb 2007 15:36 GMT
>   > would you please tell me what this use-case thing is? are you
>
[quoted text clipped - 7 lines]
>
> - Lew

Here is a link to wikipedia. http://en.wikipedia.org/wiki/Use_case

I've taken a number classes both in colleges and for my company, such
as C++ classes, .Net classes, and Java classes. All of these courses
jump into code. Perhaps, before writing code, we should be given a use
case or write a use case. These things need to be taught in the
schools. Same thing with books. Way too many software developers ask
"would you please tell me what this use-case thing is?" Thoughts on
that?

~ Mike
Lew - 17 Feb 2007 16:39 GMT
> Here is a link to wikipedia. http://en.wikipedia.org/wiki/Use_case
>
[quoted text clipped - 5 lines]
> "would you please tell me what this use-case thing is?" Thoughts on
> that?

Programming is not about computers.

Every programmer should be aware that computers are a nuisance.

Programming is not about programmers.

Every programmer should be aware that programmers are a nuisance.

Programming is not about oneself.

Every programmer should be aware that they are a nuisance.

Be responsible for this.

- Lew
blmblm@myrealbox.com - 16 Feb 2007 13:57 GMT
> >>> ...
> >>>>     Perhaps some of the confusion is arising because you haven't
[quoted text clipped - 16 lines]
> I see where you are coming from with this.  Once I figure out the methods I
> want to add, I'll come up with some use-cases.

With all due respect, I wonder if you do see where she's coming
from, since defining methods and then use cases seems to me to
make little sense.  I may be quibbling about wording here, though,
since if you said you wanted to figure out the methods and then
explore example uses that would seem -- well, still different from
what Patricia is advising, but not as nonsensical.

But I *think* I also get your viewpoint:  Many (most?) books
and tutorials on Java use examples like your Animal hierarchy to
explain classes and inheritance and so forth, and if you're one of
those people who doesn't quite get something until you've turned
it into your own code (I'm kind of like that), it's hard to resist
doing, well, something like what you're doing.  It strikes me as a
fairly reasonable way to learn about the mechanisms of classes and
inheritance and so forth, but not so good for learning about good
object-oriented design.  My two cents' worth!

Signature

B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

MikeNereson - 16 Feb 2007 13:39 GMT
> What's the point of having a use case if what I am doing is not going to be
> used for anything except my own curiousity and education?  Doesn't a
[quoted text clipped - 4 lines]
> Maybe I'll just go away and read some more... I come here for clarification,
> it is not my intention to cause confusion.

If you had documented use-cases, you would know what your software is
meant to do, and you would be able to provide us with your use-cases
so that we know what your software is meant to do. That would clear up
confusion.

I must say, I have greatly enjoyed reading this thread day after day.
I look forward to tomorrow's digest ( :

~ Mike
John T - 15 Feb 2007 19:07 GMT
>    I.e. you're not modeling individual cats, but the concept of a cat
> itself. Thus your classes might be Phylum, Order, Family, Genus, etc.

Too many ways to divide.  I did a google search trying to figure out how to
subdivide animals into their various groups.  Once I started looking at
phylum, I ended up with subphylums, familys, orders...just way to complex.

My model may not be 100% realistic, but for simplicity's sake, I figured I'd
choose some very simple yet specific animals

HouseCat
DomesticDog
Deer
Moose
Mouse
Wolf
Coyote
Lion
Tiger
Bear
Snake
Human

and then start factoring attributes out to come up with superclasses.

All I want to do is practice what I've learned about classes and
encapsulation and inheritance.  I haven't gotten too deep into abstract
classes yet but have looked at interfaces, so I'm trying to start with what
I know about and build on it as I learn more.

      x                Is-A       y
HouseCat         IS-A    Cat  - yes
DomesticDog   IS-A Dog - yes
Wolf                IS-A Dog - yes

to me the principle is pretty simple.  If you have something like "SodaPop"
as a class and then you have "Pepsi" as a class, then if you can say "Pepsi"
IS-A "SodaPop", then Pepsi can extend SodaPop.  The diagram below is not
100% correct from a scientific view point, but for my little (but very
important for me to be able to grasp the concepts) it will describe quite
well what I think my class structure should look like...at least initially
(I left out ones lik Snake and Moose for simplicity).

                                                                  Animal
                                                                       |
               --------------------------------------------------------------------
               |                        |                             |
|                    |
              Cat                   Dog                       Mouse
Bear              Human
               |                        |

     -------------      -------------                               -----------------
     |                  |     |                    |
|                         |
  HouseCat   Lion  Wolf      DomesticDog              PolarBear
GrizzlyBear
Tor Iver Wilhelmsen - 17 Feb 2007 08:35 GMT
> This is an educational experience for me.  I am making my way through some
> of the more popular books on Java Programming and am trying to put what I
> learn into practice with real-world scenarios.

If by "real-world" you had meant "practices for real-world development
work" instead of "real-world object classification" I would have
strongly advised you to create as few classes as possible and instead
express differences between objects via properties, behaviours and the
like you "plugged in" via composition of the classes, and the only
subclassing used was when you discovered common behavior between
generalized classes that you refactor into a superclass.

Don't create large class hierarchies just because it used to be "chic"
back in the 1980s.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.