protected member OOP question

[StGuru]

I got one question about protected members.

Here is the 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.

[zerocool2k]

Because when you write

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

[laserlight]

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.

[StGuru]

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?

[laserlight]

And why when I put protected it works? Is it inherited like protected member?

Yes.

Why the inherited class does not inherit the private members of the original class?

They do, but those members are not accessible.

[StGuru]

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?

[andrey_zh]

With a help of interface methods, for example...

#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;
    
}

[StGuru]

Thanks, it worked.

[StGuru]

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.

[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.

[Mybowlcut]

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...

[andrey_zh]

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.

[Mybowlcut]

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.

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?

[laserlight]

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.

[Mybowlcut]

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.