Java Forum / First Aid / February 2007
classes and inheritance revisited
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 MagazinesGet 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 ...
|
|
|