Some Questions From Head First Java

[Michael Hubele]

I am doing chapter 7 from the head first Java book and I doing a sharpen your pencil question(179)

Instructions:

Put a check next to the relationships that make sense: I am using the is-a and then I going one step further by trying if it could be a has a.

Oven extends Kitchen - Oven is a Kitchen - does not work if it was Kitchen has a oven then that would mean oven is a instance variable of Kitchen?

Guitar extends instrument - Guitar is a instrument - makes sense so Guitar can inherate from instrument.

Person extends Employee - Person is a Employee - not sure about this one is sounds like it makes sense but not sure though but I guess sicne not every person is a employee it would not work.

Ferrari extends Engine - Ferrari is a Engine - does not make sense but ferrair has a Engine so Ferrari would be a instance variable of Engine?

FriedEgg extends Food - FriedEgg is a Food - makes sense so FriedEggy inherates from Food

Beagle extends Pet - Beagle is a pet - makes sense so Beagle inherates from Pet.

Container extends Jar - Container is a Jar - could make sense too since a Container could be a Jar.

Metal extends Titanium - metal is a Titanium - does not make sense so it does not work. Since not all metal is Titanium

GratefulDead extends Band - GratefulDead is a Band - it works

Blonde extends Smart - Blonde is a Smart - to me that does not make sense but according to the answers I found it works.

Beverage extends Martini - Beverage is a Martini -- this one to me could work too since martini could be classified as Beverage but then again not every beverage is a Martini.

[Mark Van Tuyl]

I have a few comments:

"Person extends Employee - Person is a Employee - not sure about this one is sounds like it makes sense but not sure though but I guess sicne not every person is a employee it would not work."

It works the other way around - every Employee is a Person.


"Ferrari extends Engine - Ferrari is a Engine - does not make sense but ferrair has a Engine so Ferrari would be a instance variable of Engine?"

Ferrari has an Engine, so Ferrari would implement the Engine interface.


"Container extends Jar - Container is a Jar - could make sense too since a Container could be a Jar."

But not all Containers are Jars. The reverse works: Jar is a Container so Jar extends Container.


"Beverage extends Martini - Beverage is a Martini -- this one to me could work too since martini could be classified as Beverage but then again not every beverage is a Martini."

Again, it's reversed - Martini is a Beverage, so Martini extends Beverage.

[Joel McNary]

I have a few comments:

"Ferrari extends Engine - Ferrari is a Engine - does not make sense but ferrair has a Engine so Ferrari would be a instance variable of Engine?"

Ferrari has an Engine, so Ferrari would implement the Engine interface.



Implementing an interface is a type of "is-a" relation, not "has-a." So an Engine would be an instance variable of a Ferrari.

Now, back to the OP---

When you extend/implement a superclass/interface, you are narrowing the possibilities. I like to think of it in terms of Linnean Taxonomy:

class LivingThing {}
 
class Anamalia extends LivingThing{}
 
class Chordata extends Anamalia{}
 
class Mammalia extends Chordata{}
 
class Carnivora extends Mammalia{}
 
class Felidae extends Carnivora{}
 
class Leopardus extends Felidae{}
 
class Pardalis extends Leopardus{}

Note that each extension adds a level of specificality. We could go in and fill in more and more details at each level (attributes, like "spinalCord" at the "Chordata" level, and methods, like "giveBirthToLiveYoung()" at the "Mammalia" level), until finally we've gotten specific enough that we can accurately describe an ocelot.

[Bert Bates]

 
class LivingThing {}
 
class Anamalia extends LivingThing{}
 
class Chordata extends Anamalia{}
 
class Mammalia extends Chordata{}
 
class Carnivora extends Mammalia{}
 
class Felidae extends Carnivora{}
 
class Leopardus extends Felidae{}
 
class Pardalis extends Leopardus{}
 

Ouch! Cognitive overload

What the heck is a Pardalis?

Wouldn't it be easier on the brain to say:

class LivingThing
class Animal extends LivingThing
class Dog extends Animal
class Beagle extends Dog


Same idea but Pardalis' seem to distract from the actual learning topic...

[Rusty Shackleford]

Implementing an interface is a type of "is-a" relation, not "has-a." So an Engine would be an instance variable of a Ferrari.

You could have Ferrari implement an Engine interface. Unless of course, there is an Engine class heirarchy.

When I see a has-a relationship I normally think interface(not always the interface keyword).

[Joel McNary]

But if I have a Truck, I can't install a Ferrari as it's Engine. (Of course, that's assuming that a Truck is composed of an Engine instead of itself being an implementation of an engine).

More importantly, If I have a Ferrari, I can change it's Engine. A Ferrari is composed of an Engine (and some other stuff). Composition is "has-a"

 
public class Ferrari
    extends Car // <----- Is-a section
    implements PersonMover   // <-----  Still Is-a
{
    //The Has-a section starts here
    public int doorCount;
    public String modelName;
    public Engine engine;
 
    ////methods
   public performReallyExpensiveWorkBecauseTheEngineFailed(Engine newEngine){
        engine = newEngine;
    }
}

If I need a different Engine, I can do it because a Ferrari has an Engine. If a Ferrari is an engine and I need a new engine, then I need a whole new car because I can't replace the engine.