protected member OOP question
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 18

Thread: protected member OOP question

  1. #1
    Join Date
    Mar 2009
    Posts
    82

    Arrow 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 01:02 PM.

  2. #2
    Join Date
    Nov 2008
    Location
    OK, US
    Posts
    63

    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

  3. #3
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,345

    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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  4. #4
    Join Date
    Mar 2009
    Posts
    82

    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?

  5. #5
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,345

    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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  6. #6
    Join Date
    Mar 2009
    Posts
    82

    Re: protected member OOP question

    Quote Originally Posted by laserlight View Post
    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?

  7. #7
    Join Date
    Mar 2009
    Location
    Riga, Latvia
    Posts
    128

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

  8. #8
    Join Date
    Mar 2009
    Posts
    82

    Re: protected member OOP question

    Thanks, it worked.

  9. #9
    Join Date
    Mar 2009
    Posts
    82

    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.

  10. #10
    Join Date
    Nov 2008
    Location
    England
    Posts
    748

    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.

  11. #11
    Join Date
    Nov 2006
    Location
    Australia
    Posts
    1,569

    Re: protected member OOP question

    Quote Originally Posted by Russco View Post
    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...
    Good judgment is gained from experience. Experience is gained from bad judgment.
    Cosy Little Game | SDL | GM script | VLD | Syntax Hlt | Can you help me with my homework assignment?

  12. #12
    Join Date
    Mar 2009
    Location
    Riga, Latvia
    Posts
    128

    Re: protected member OOP question

    Quote Originally Posted by Mybowlcut View Post
    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 07:32 AM.

  13. #13
    Join Date
    Nov 2006
    Location
    Australia
    Posts
    1,569

    Re: protected member OOP question

    Quote Originally Posted by andrey_zh View Post
    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 View Post
    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?
    Good judgment is gained from experience. Experience is gained from bad judgment.
    Cosy Little Game | SDL | GM script | VLD | Syntax Hlt | Can you help me with my homework assignment?

  14. #14
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,345

    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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  15. #15
    Join Date
    Nov 2006
    Location
    Australia
    Posts
    1,569

    Re: protected member OOP question

    Quote Originally Posted by laserlight View Post
    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.
    Good judgment is gained from experience. Experience is gained from bad judgment.
    Cosy Little Game | SDL | GM script | VLD | Syntax Hlt | Can you help me with my homework assignment?

Page 1 of 2 12 LastLast

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
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center