Program of inheritance

Hi Guys,

I am making a program on inheritance, I have made a small program of automobile and want to make sure that 2 cars(base class) inherit the characteristics of the parent class(Vehicle).

This is the extract from the program:

Code:

---

class Vehicle

{

private:

int modelno;
char name;


public :

int getmodel();
int setmodel();


};

class Car:public Vehicle

{


};

---

----------------------------------------------------------------------

I wanted to know that do I have to define the functions "int getmodel()" and "int setmodel()" in the base class "Car" or it will inherit these functions from the parent class "Vehicle"?

Will this class Car inherit the data members from the parent class "Vehicle" itself?

Thanks

Quote:

---

Originally Posted by student111

I wanted to know that do I have to define the functions "intgetmodel()" and "intsetmodel()" in the base class "Car" or it will inherit these functions from the parent class "Vehicle"?

---

Car is not a base class. Veichle is a base class.
As for your question, Car will inherit them.

Quote:

---

Will this class Car inherit the data members from the parent class "Vehicle" itself?

---

Yes, it will inherit them, but it can't access them since they're private.

Refer to the tutorial for more info:
Inheritance in C++ Syntax Tutorial - Cprogramming.com

Yes sorry I made a mistake, I meant that can the derived class (Car) inherit from the base class(Vehicle).


So do I have to define a function in the child class to make sure that it can access the private data members of the parent class "Vehicle"?

Thanks

Quote:

---

Originally Posted by student111

So do I have to define a function in the child class to make sure that it can access the private data members of the parent class "Vehicle"?

---

No, you must do it in the base class (because the derived class does not have access to those members).
Or, you can use the protected identifier instead of private.
Nevertheless, it is always a good idea to use getters and setters to all members.

If you have more derived class which may inherit the class Vehicle and the behavior of getmodel() and setmodel() you want to design specific to the derived class then your problem has a solution of virtual functions.

Quote:

---

Originally Posted by Elysia

Nevertheless, it is always a good idea to use getters and setters to all members.

---

Wait....what?!

Surely that should be: Making getters and setters is the last resort, if you can't think of a design where the outside doesn't need direct access to member variables?

Wait, what? I can't make sense of your statement >_<

He's saying that ideally, users of a class shouldn't require access to a class's internal state at all, neither directly nor through getters and setters, and I'd have to agree with him. If you have a class with tons of getters and setters, that's a pretty good indicator that you need to rethink your design.

I did not say they have to be public. Furthermore, what these getters and setters actually do is obviously up to the implementation.
The more getters and setters, the better you are protected against code changes. The tradeoff is time. Don't expose getters and setters to members that should not be public to the outside world.

Quote:

---

Originally Posted by Elysia

The more getters and setters, the better you are protected against code changes.

---

Not really: there's still the "problem" that member functions and friends don't actually have to use them. I would prefer a minimal but complete interface where member functions and friends are concerned instead to "protect" against changes to the internals of the class. In such a case, you don't really gain much from private getters and setters.

If you have access to internals, you have to use them wisely. Using public functions is preferred over directly manipulating members. It protects more against changes.
All I am trying to convene is that if you use an extra indirection--that is, getters and setters--you protect yourself from code changes better than if without (this obviously means the code have to use them; otherwise they're render useless). This is strictly different from minimal interfaces and such. It doesn't replace them; it complements them, if you will.

O_o

The others here aren't arguing what you apparently think.

Using "getters" and "setters" that isolate the underlying type from an interface is great.

Using "getters" and "setters" that isolate a mechanism by which the underlying type is manipulated is great.

What everyone is saying is that even other members in the class should be written, if at all possible, in such a way that the mechanic and interface types are properly isolated by intent as a real interface doing a real thing.

In other words, instead of the function `void OSomeClass::doSomethingFancy()' using `int OSomeClass::Get()' and `void OSomeClass::Set(int)' directly it will use `void OSomeClass::doSomethingAwesome()'. With the interface and implementation so designed changes to members are already isolated by intent; the extra isolation granted by "getters" and "setters" doesn't give you anything.

Soma

Am I the only one wondering how this method will work?

Code:

---

int setmodel();

---

Tim S.
PS: C programmer learning C++.

Quote:

---

Am I the only one wondering how this method will work?

---

^_^;

Now that you mention it.

Soma

That is easy to explain... the vehicles here are just plain old transformers.