For the sake of discussion, say I have a sphere class with a few public and private methods. Since I have this generic class I would like to define a second class that is more specific of the type, like balls, bearings, and so on. So for my second class I make this declaration:

class kind:public spehre { 
...

Sphere is the base class and kind is the derived class. Now I have access to the public methods and members of the class sphere.

So my question is this. How is what I just did different than declaring an instance of the sphere class in my kind class?

class kind{
sphere type;
...

I would be granted the same access as I did above. Is there something I'm missing? Is the second way possible, but not good programming?

hi
First of all, there are 3 basic relationships between classes / or object of classes:

1. Is-a relationship - called Inheritance -> The derived class is a base class with extended capabilities. (Like in your first example)

2. Has-a relationship - called Embedded class / Composition -> A class A has an object of another class as data member. (Like in your 2nd example)

3. Has-access-to relationship - friend classes -> An object of a class A has access to the object of a class B.

Now the differences:
A. Relationships 1. and 2. differ to relationship 3. in the way that they are both "destructive" relationships, while 3. is not: Objects to which A has access are not destroyed. when A is destroyed.
B. Relationship 1. differs to relationship 2. in the way that: In Inheritance: "First the base class is fully constructed, then the derived class." while when using an embedded class: "The constructors for the embeddings are called before the body of the object's constructor is executed."

So regarding:

Is the second way possible, but not good programming?

I would say it depends on what u want to do..
:D

commented: nice explaination :) +36

First I must correct myself because the difference between the relationships 1 and 2 is the ORDER OF DESTRUCTION(THE ORDER OF CONSTRUCTION IS THE SAME).

Moreover I would like to note that in your second example the embedded object used is equivalent like I said in the previous post to "Composition (Has-a relationship)".

However there is one more kind of embedded objects :
those embedded objects which are declared as pointers
This is the case of the 4rth kind of relationship: Aggregation. In this case the object of a class A, NOT ONLY has-a object of a class B but owns it too.

In this owns-a relationship Object A IS RESPONSIBLE FOR OBJECT'S B ALLOCATION & DEALLOCATION.

So if we put them all together:

1. Is-a/Inheritance <-> B Object is-a A Object :
Class A {};
Class B:public A
{
};
-> A is constructed
B is constructed
B is destructed
A is destructed

2. Has-a / Composition relationship <-> B Object has-a Object
Class A {};
Class B
{
...
private:
A anObjectA;
};
-> A(embedded) is constructed
B is constructed
A(embedded) is destructed
B is destructed

3. Has-access-to /Friend relationship <-> B Object has-access-to Object A
Class A {};
Class B
{
friend class A;
public:
B(const A& ObjectA) : ....,anObjectA(ObjectA) {}
...
private:
A& _anObjectA;
};

4. Owns-a/Aggregation relationship <->B Object has-access and owns Object A
Class A {};
Class B
{
public:
....
B():..... {_anObjectA=new A[n]}
~B() {delete []_anObjectA;}
private:
....
A* _anObjectA;
};

Great! Thanks for the help!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.