protected member OOP question
I got one question about protected members.
Here is the code:
Code:
#include <iostream>
using namespace std;
class osnovna
{
protected:
int test;
};
class izvedena : private osnovna
{
public:
void funkcija()
{
cin>>test;
cout<<test;
}
};
class izvedena1 : public izvedena
{
public:
void tesit()
{
cin>>test;
cout<<test<<endl;
}
};
int main()
{
izvedena dva;
dva.funkcija();
system("PAUSE");
return 0;
}
Why when I write izvedena : public osnovna, or izvedena : protected osnovna the izvedena1 class can access the variable test and with private not?
Can somebody elaborate please?
Thanks in advance.
Re: protected member OOP question
Because when you write
Code:
izvedena : private osnovna
the member test becomes private in izvedena. So, all derived classes from izvedena cannot access that member.
You should do some more reading, like here:
http://www.parashift.com/c++-faq-lit...heritance.html
Re: protected member OOP question
Quote:
Originally Posted by StGuru
Why when I write izvedena : public osnovna, or izvedena : protected osnovna the izvedena1 class can access the variable test and with private not?
All the members inherited from a private base class become private members of the derived class, so it is as if you declared test as private in izvedena.
Re: protected member OOP question
Thanks for the replies. And why when I put protected it works? Is it inherited like protected member?
I got another question. Why the inherited class does not inherit the private members of the original class?
Re: protected member OOP question
Quote:
Originally Posted by StGuru
And why when I put protected it works? Is it inherited like protected member?
Yes.
Quote:
Originally Posted by StGuru
Why the inherited class does not inherit the private members of the original class?
They do, but those members are not accessible.
Re: protected member OOP question
Quote:
Originally Posted by
laserlight
Yes.
They do, but those members are not accessible.
They are not accessible by any possible way? Is there any way that I can access them?
Re: protected member OOP question
With a help of interface methods, for example...
Code:
#include <iostream>
using namespace std;
class osnovna
{
public:
int get_test( void ) { return test; }
protected:
int test;
};
class izvedena : private osnovna
{
public:
void funkcija() // it would be better to call this a 'method'
{
// cin>>test;
cout<<get_test();
}
};
/*
class izvedena1 : public izvedena
{
public:
void tesit()
{
// cin>>test;
cout<<test<<endl;
}
};
*/
int main()
{
izvedena dva;
dva.funkcija();
system("PAUSE");
return 0;
}
Re: protected member OOP question
Re: protected member OOP question
I noticed when I put class izvedena : public osnovna then the protected member test becomes again protected, but if I put private it becomes private inside the inherited class.
Re: protected member OOP question
IMHO you should never use protected data members.
You should consider the 3 sections of a class as :-
public :- The interface to calling code. Defines the behaviour of the object.
protected :- The interface to derived classes. This is where functions needed by derived classes but not by client code live.
private :- The implementation details area. This is where your data members and internal to the class functions should be.
You should view both the public and protected sections as interface sections. There should be no implementation in an interface. Any data member is very much an implementation detail.
Re: protected member OOP question
Quote:
Originally Posted by
Russco
IMHO you should never use protected data members.
You should consider the 3 sections of a class as :-
public :- The interface to calling code. Defines the behaviour of the object.
protected :- The interface to derived classes. This is where functions needed by derived classes but not by client code live.
private :- The implementation details area. This is where your data members and internal to the class functions should be.
You should view both the public and protected sections as interface sections. There should be no implementation in an interface. Any data member is very much an implementation detail.
I always hear this being said, but when I think about applying it to my programs, I realise that I've have to create so many Get and Set functions to access the data that I just made private that it's not worth it...
Re: protected member OOP question
Quote:
Originally Posted by
Mybowlcut
I always hear this being said, but when I think about applying it to my programs, I realise that I've have to create so many Get and Set functions to access the data that I just made private that it's not worth it...
It's a violation of the most fundamental OOP rule: Hide as much as you can. It's a rather bad thing when you write a library.
Consider using preprocessor to make private fields public only on debugging stage of development(1), and generalize your classes(2) - write generalized methods and/or provide a flexible interface.
In most cases all the inheritance hierarchy works as all at once. E.g. when you have a class Vehicle you already know that you need Bike, Car and Ship, but not, say, Plane. So you know what to show and what to hide from derived classes.
Re: protected member OOP question
Quote:
Originally Posted by
andrey_zh
It's a violation of the most fundamental OOP rule: Hide as much as you can. It's a rather bad thing when you write a library.
I understand that, but like I said, I don't see how making everything private is beneficial when in most cases you have to make Get/Set functions to get around it anyway.
Quote:
Originally Posted by
andrey_zh
Consider using preprocessor to make private fields public only on debugging stage of development(1), and generalize your classes(2) - write generalized methods and/or provide a flexible interface.
In most cases all the inheritance hierarchy works as all at once. E.g. when you have a class Vehicle you already know that you need Bike, Car and Ship, but not, say, Plane. So you know what to show and what to hide from derived classes.
Not really sure what you mean. Care to post a code sample?
Re: protected member OOP question
Quote:
Originally Posted by Mybowlcut
I don't see how making everything private is beneficial when in most cases you have to make Get/Set functions to get around it anyway.
If you need to have getters and setters in most cases, then it implies that in many cases you have a poor class design that does not provide a relevant class interface. In those cases where there is a genuine need for getters and setters, they have an advantage over providing direct access to the member variable since the option of changing the member variable without breaking client code remains.
Re: protected member OOP question
Quote:
Originally Posted by
laserlight
If you need to have getters and setters in most cases, then it implies that in many cases you have a poor class design that does not provide a relevant class interface. In those cases where there is a genuine need for getters and setters, they have an advantage over providing direct access to the member variable since the option of changing the member variable without breaking client code remains.
I'm going through my code trying to find an example but I'm not having much luck... when I find one I'll post it here. But basically, my class design isn't "poor" as I don't encounter any problems with it. Perhaps with a large library with many clients like andrey_zh mentioned, it would be a bigger issue.