Inheritance vs Composition

Ive been reading a book called Thinking in C++ by Bruce Eckel and came across an interesting point. He mentioned somewhere that for many newcomers, inheritance is often over-emphasized and it is more practical for most situations to use composition instead. (Composition is objects within another) I personally found this to be true as I have never actually found inheritance as the *only* or *best* means of accomplishing a task and many times have found the method composing to make much more conceptual sense. Take for example a class called carpark, and a class called car. It is obvious you would not inherit carpark to car but you would want to somehow encapsulate them. (so an answer I see to this is composition, i.e. an array of cars within a carpark perhaps) My question is when is inheritance *actually* needed? (And yes I know of the classic twodshape, triangle, redTriangle etc example.) And do you think it's true that the inheritance concept is over-emphasized by tutorials?

>My question is when is inheritance *actually* needed?

try writing a GUI some time.

>And do you think it's true that the inheritance concept is over-emphasized by tutorials?

no, but "Composition" is under-emphasized.

Nothing is ever "needed," but inheritance has unlimitted uses.

The example you gave would be better off as encapsulation.

Examples where inheritance is better are anytime you want the new class to be a "kind of" it's parent. A carpark is not a "kind of car," it just has cars.

However, what if you wanted a jeep, corvette, beetle, etc.

This is one place inheritance makes more sense.

You make a base class car which has common interfaces and maybe some common data to all cars.

You derive from that class a "jeep" and a "corvette" and a "beetle" and any nubmer of unlimitted possibile kinds of cars there are.

Now you have 3 kinds of cars which are still separate datatypes but share a common base.

If you had gone the other route, it wouldn't make much sense. A corvette doesn't "have a car" it "is a kind of car." See the relationship?

The reason that inheritance is usually emphasized more is because encapsulation is a much more basic concept and it is a lot easier for people to grasp so it usually doesn't need as much of an explanation.

That clears some things. Thanks.
Next question is how do you write a GUI?
I have a vague idea that this process is very hard and Im not expecting an answer to my silly question. What I mean to ask is what must I first learn (besides C++ fundamentals and methods) to make GUIs?

That totally depends on what platform you're programming (then again, there are multiplatform libraries...)

Whatever the platform, you must simply read _all_ of the documentation - several times, if necessary. Once you understand the underlying principles and API, you begin a long and painful process of actually coding it. :)

Initially, I was - er - shocked when I saw the source for a Windows program for the first time. I was like "is this C, or some new language??". Not very promising at the first look. But as time goes on, it becomes more familiar...but be realistic, and expect at least 6 months to a year before you are proficient at it.

>
I have a vague idea that this process is very hard and Im not expecting an answer to my silly question.
<

it's not easy, it requires a lot of predesign, or else it hurts a lot more than it should.

>
What I mean to ask is what must I first learn (besides C++ fundamentals and methods) to make GUIs?
<

a lot, to put it bluntly, mostly it comes down to pure coding exerience but what else you need to know and how difficult it is depends on many factors, like on what it needs to do and how complicated that it is, and what the underlying system it needs to communicate with is, plus how versatile/flexible it must be, and let me restate, how much preplanning you have, is it portable, ect...

I have a question I would like clearing up for me. There seems to be so many terms for 'composition' (i.e. aggregation is another) and I get confused between them.

What is meant precisely by 'composition' and/or 'aggregation'? Here are two different examples. Is it A or B? Or both? Or neither?

Example A

I have a class Car. And I produce a class SportsCar which has Car as a public member, like so:

Code:

---

class SportsCar
{
public:
  Car carObj;
};

---

Therefore SportsCar is a composite. Is this right? Or is it the slightly more sophisticated example B, below:


Example B

My Car class now has a method for returning the number of wheels, like so:

Code:

---

int Car::NumOfWheels() const;

---

Now I could build my SportsCar class so that it inherits from Car. However, I chose not to, but instead I do the following:

Code:

---

class SportsCars
{
private:
  Car pCar;
public:
  int NumOfWheels() const;
};

---

Notice I has placed the Car object as a private member & reproduced its method(s) explicitly in SportsCar public. The implementation of SportsCar::NumOfWheels can be just a pass through to pCar, like so:

Code:

---

int SportsCar::NumOfWheels() const
{
  return pCar.NumOfWheels();
}

---

Is this what is meant by composition?

I ask this question because I often hear that 'VB doesn't support inheritance, but supports aggregation instead.' Example B seems a way [albeit a laborious one] of replicating some features of inheritance.

Aggregation:

Code:

---

class Car
{
};

class SportsCar
{
    Car m_Car;
};

---

Inheritance:

Code:

---

class Car
{
};

class SportsCar
    : public Car
{
};

---

Thanks for the reply.

Now I'm clear on aggregation? Is it the same as 'composition'?

Example B is more interesting to me. What is the name for this technique (if there is one)? Subclassing maybe?

I ask because there are some special cases where using it may be necessary rather than using true inheritance. There was a post not too long ago concerning this:

http://cboard.cprogramming.com/showt...hlight=virtual

Quote:

---

Originally posted by Davros
Now I'm clear on aggregation? Is it the same as 'composition'?

---

yup

Ah...the wonders of abstract classes...

Code:

---

class Car
{
    protected:
        Car();
    public:
        int wheels;
       
        virtual void StartEngine() = 0; // each car's engine startes differently...I think

};

class SportsCar : public Car
{
    public:
        virtual void StartEngine(); // over ride
};

---

Thanks.