beginning java...nublet drowning. throw me a lifeline?

[Justin Fondriest]

//Reusing the implementation

//**The simplest way to reuse a class is to just use an object of that
class directly, but you can also place an object of that class inside
a new class. We call this "creating a member object." Your new class
can be made up of any number and type of other objects, in any
combination that you need to achieve the functionality desired in your
new class.
Because you are composing a new class from existing classes, this
concept is called COMPOSITION(if the composition happens dynamically,
it's usually called AGGREGATION). Composition is often referred to as
a "has-a" relationship, as in "A car has an engine."***//


Ok...so is this saying "a car has an engine", with regard to code
would be more like "a car (class)"--as in every car class--"has an
engine(object)"?


Now whether I am right or wrong...could someone take maybe 3 minutes
to explain what composition is in layman's terms?

does it have anything to do with the "import" feature that you put in
a program before you "instantiate"(?) the class?

Thanks for anyone willing to help...I am trying to learn to code so,
hopefully, I can do something good for the world with it...but I think
I may be a good candidate for the slow bus when it comes to java...

 

[Eric Sosman]

//Reusing the implementation

//**The simplest way to reuse a class is to just use an object of that
class directly, but you can also place an object of that class inside
a new class. We call this "creating a member object." Your new class
can be made up of any number and type of other objects, in any
combination that you need to achieve the functionality desired in your
new class.
Because you are composing a new class from existing classes, this
concept is called COMPOSITION(if the composition happens dynamically,
it's usually called AGGREGATION). Composition is often referred to as
a "has-a" relationship, as in "A car has an engine."***//


Ok...so is this saying "a car has an engine", with regard to code
would be more like "a car (class)"--as in every car class--"has an
engine(object)"?


Now whether I am right or wrong...could someone take maybe 3 minutes
to explain what composition is in layman's terms?

"Car has an Engine" is pretty good. You might have an entire
hierarchy of different kinds of engines: The archetypical unspecialized
Engine, subclasses GasolineEngine and DieselEngine and SteamEngine,
and maybe OttoEngine and WankelEngine as further specializations of
GasolineEngine.

You might also have a hierarchy of different kinds of Car:
Automobile (with subclasses FamilyCar, RacingCar, StanleySteamer,
and RustBucket), TrolleyCar, TramCar, and so on.

But one thing every Car instance of whatever kind has is some
kind of power source: An Engine. So your generic Car might have
an internal Engine reference, and you might call theCar.getEngine()
to discover what particular kind of Engine a particular Car has.
If the Car is a RacingCar it (almost certainly) has an OttoEngine,
if it's a StanleySteamer it surely has a SteamEngine, but the point
is that every Car of whatever kind (in your program's view of the
world) has some kind of Engine.

It would not be correct to say "A Car *is* an Engine." It would
be correct to say "A Car *has* an Engine." If you see a need to
capture the fact in your program, it might also be correct to say
"An Engine *belongs to* a Car."

Note that these "is a" and "has a" and "belongs to a" relations
(and others) are not Immutable Facts About The Universe. Your program
works with a model, an abstraction of those features of reality that
you care about, and you may or may not give a rat's patootie about the
kind of Engine in a Car: You're a traffic cop, and all you need to know
is that the Car has just run a red light, using a source of power that
you care less than nothing about. But then again, maybe you're an
auto mechanic and vitally concerned not only with the kind of Engine
in the Car, but whether its serial number is or is not part of the
manufacturer's safety recall program. The features and relations you
decide to model in your program are governed by the problems you're
trying to solve.

does it have anything to do with the "import" feature that you put in
a program before you "instantiate"(?) the class?

No. "import" is a convenience, that's all. You could write all
the Java you like without ever using "import" -- at the cost of
writing out almost every class name in full. That is, you could
omit that "import java.util.ArrayList;" line altogether, but then
you'd have to write

java.util.ArrayList theList = new java.util.ArrayList();

instead of

ArrayList theList = new ArrayList();

The *only* thing "import" does is allow you to omit the "java.util."
(or "javax.swing." or whatever) when you mention a frequently-used
class. "import" has nothing to do with inheritance, or composition,
or the price of tea in China.

Thanks for anyone willing to help...I am trying to learn to code so,
hopefully, I can do something good for the world with it...but I think
I may be a good candidate for the slow bus when it comes to java...

Don't give up. I came to Java after forty-odd years of writing
in various other languages, and even with my vast (or half-vast)
experience I found there was a period where I simply didn't "get it."
But stick with it, and things will jell rather rapidly: The fog will
crystallize (that makes it snow, right?) and the air will clear. I
think you'll find that the "hump" for Java comes sooner rather than
later; Java is a lot less arcane than some other languages you'll
encounter.

 

[markspace]

Ok...so is this saying "a car has an engine", with regard to code
would be more like "a car (class)"--as in every car class--"has an
engine(object)"?

This is more or less correct. Don't forget that the engine is also a
class, and not an object, until you instantiate the Car, then you have
both a Car object and an Engine object;

class Car {
Engine engine = new Engine();
}

There's no objects in the above code until someone calls "new Car()".

Now whether I am right or wrong...could someone take maybe 3 minutes
to explain what composition is in layman's terms?

You were pretty close.

does it have anything to do with the "import" feature that you put in
a program before you "instantiate"(?) the class?

Nope, not a darn thing.

 

[Roedy Green]

Now whether I am right or wrong...could someone take maybe 3 minutes
to explain what composition is in layman's terms?

see http://mindprod.com/jgloss/isa.html

There are two ways to extend a class.

An Elephant class might extend a Mammal class because an elephant is a
mammal.

An Elephant class might have a variable of the Trunk class because an
elephant has a trunk

That is all that gobbledygook means.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Programmers love to create simplified replacements for HTML.
They forget that the simplest language is the one you
already know. They also forget that their simple little
markup language will bit by bit become even more convoluted
and complicated than HTML because of the unplanned way it grows.
..

 

[Arved Sandstrom]

see http://mindprod.com/jgloss/isa.html

There are two ways to extend a class.

An Elephant class might extend a Mammal class because an elephant is a
mammal.

An Elephant class might have a variable of the Trunk class because an
elephant has a trunk

That is all that gobbledygook means.

I don't like thinking of composition (has-a) as extension - usually. You
didn't extend "Trunk" at all: there is no other new class in the system
that "is-a" Trunk.

I could see the use of the word "extend", more in the natural language
sense than in the OO sense perhaps, if we talked about some object-based
structural patterns where composition is used, and it had to do with
"reshaping" objects of a single class (degenerate composites, so to
speak). For example, decorator or object-based adaptor.

However, as soon as composition is being used to assemble a brand new
thing, out of several or many objects of various classes, I don't really
see any "extension".

AHS

 

[Lew]

This is more or less correct. Don't forget that the engine is also a class,
and not an object, until you instantiate the Car, then you have both a Car
object and an Engine object;

class Car {
Engine engine = new Engine();
}

There's no objects in the above code until someone calls "new Car()".


You were pretty close.


Nope, not a darn thing.

You should google around for these concepts, too. Perhaps the most essential
skill in programming is the ability to find out stuff when there's no one
around to ask. What research did you do before asking here?

The Java tutorials discuss 'import'. 'import' has no functional action in a
program. It is simply a declaration to the compiler which of several possible
packages you mean to use for a given name.

Composition - "has-a" - the meaning of "has-a" is intended to be as in English
- something has something.

Inheritance or Extension (in the Java sense) - "is-a" - the meaning of "is-a"
is intended to be as in English - something is something.

The Car analogy is very simplified, remember, but it makes the case.

Is an engine a car?
Is a car an engine?

No. "is-a" doesn't apply, so we do not see 'public class Car extends Engine'.

In our model (but not necessarily in real life), a car "has an" engine, so we
use the "has-a" cue, meaning the class 'Car' has (yep, has) an element to
represent the engine.

public class Car
{
private Engine engine; // + associated get...(), set...() methods
}

Putting a member inside a class definition is called "composition" because a
class's shape, or structure, is composed of those members.

For most purposes, composition is better than inheritance in Java.