-
June 28th, 2009, 11:56 AM
#1
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.
Last edited by StGuru; June 28th, 2009 at 12:02 PM.
-
June 28th, 2009, 12:23 PM
#2
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
-
June 28th, 2009, 12:28 PM
#3
Re: protected member OOP question
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.
-
June 28th, 2009, 12:42 PM
#4
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?
-
June 28th, 2009, 12:47 PM
#5
Re: protected member OOP question
Originally Posted by StGuru
And why when I put protected it works? Is it inherited like protected member?
Yes.
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.
-
June 28th, 2009, 01:40 PM
#6
Re: protected member OOP question
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?
-
June 28th, 2009, 01:57 PM
#7
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;
}
-
June 28th, 2009, 02:37 PM
#8
Re: protected member OOP question
-
June 29th, 2009, 04:45 AM
#9
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.
-
June 29th, 2009, 05:00 AM
#10
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.
Get Microsoft Visual C++ Express here or CodeBlocks here.
Get STLFilt here to radically improve error messages when using the STL.
Get these two can't live without C++ libraries, BOOST here and Loki here.
Check your code with the Comeau Compiler and FlexeLint for standards compliance and some subtle errors.
Always use [code] code tags [/code] to make code legible and preserve indentation.
Do not ask for help writing destructive software such as viruses, gamehacks, keyloggers and the suchlike.
-
June 29th, 2009, 05:30 AM
#11
Re: protected member OOP question
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...
-
June 29th, 2009, 06:29 AM
#12
Re: protected member OOP question
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.
Last edited by andrey_zh; June 29th, 2009 at 06:32 AM.
-
June 29th, 2009, 09:12 AM
#13
Re: protected member OOP question
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.
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?
-
June 29th, 2009, 10:34 AM
#14
Re: protected member OOP question
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.
-
June 29th, 2009, 11:23 AM
#15
Re: protected member OOP question
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.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|