Thread: why private/protected vairables?

  1. #1
    Evil Sock Puppet MadHatter's Avatar
    Join Date
    Nov 2002
    Posts
    176

    Question why private/protected vairables?

    what are the advantages (if any) to declaring variables in classes private/protected? like, say you had a player class (for some sort of game), you would have...
    Code:
    class Player
    {
    public:
       void setHealth(int);
       int getHealth();
    private:
       int health;
    };
    if you can set and get the variable health, why not just have health public?

    just curious...

  2. #2
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    Have functions/methods to access internal variables means that how the variables are represented internally is irrelevant to the user. The user simply says .getHealth() and they expect the health returned. So in the next release you can store health as a character and fix your getHealth() to conver the character to an integer, and the user of your class never knows, or needs to know this change. And their code will continue to compile correctly without changing it.

  3. #3
    booyakasha
    Join Date
    Nov 2002
    Posts
    208
    Like other OOP principles, it's to reduce programmer errors, to promote encapsulation/information hiding and to reduce complexity of programming.

    Private methods/variables also often have real-world analogies. Like if you have a class called Person and the person has a variable int called age.
    Maybe in you want users of the object to be able to find out the age but not change it ( because you can't just change peoples age anyway, only time can do that ), so you can do
    class Person{
    public:
    Person();
    getAge();
    .....
    private:
    int age;
    ......
    }

    and if a user of this class does
    Person p = new Person();
    .......
    p.age = 21;

    They will get a compiler error.

    So in other words private data and functions prevent programmer errors by only allowing programmers to use/change what they are supposed to be using/changing.

  4. #4
    booyakasha
    Join Date
    Nov 2002
    Posts
    208
    Oh yeah, plus they help separate implementation from functionality, which is very important in OOP.

  5. #5
    Just a Member ammar's Avatar
    Join Date
    Jun 2002
    Posts
    953
    In a class, public members can be accessed by any function, but private and protected member are only accessed by friend functions.
    And you are dealing with inheritance, the derived class inherits the base class members( not all of them ), including the private and protected, but it can access it's base class private function through base class public members, but protected members can be accessed ty any derived class function.
    none...

  6. #6
    Registered User
    Join Date
    Aug 2001
    Posts
    411
    In any case, using getters and setters is good practice, it may may never be more than that, but later on it may make things easier on you.

  7. #7
    Evil Sock Puppet MadHatter's Avatar
    Join Date
    Nov 2002
    Posts
    176
    wow, lotsa replies..
    thanks for the info! i always used getters and setters.. i was just curious as to why
    thanks again.

  8. #8
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    It is important to also touch on one thing that goes along with encapsulation. Here is an example:

    Code:
    class base {
    public:
        virtual ~base() { }
    
        enum {
            undefined, good, bad
        };
    
        int GetStatus(void);
    
    protected:
        void SetStatus(int);
    
    private:
        int status;
    };
    
    class child : public base {
    public:
        child() {
            SetStatus(base::good);
        }
        virtual ~child() { }
    };
    Note that a child class can only modify base::status internally.

  9. #9
    Senior Member joshdick's Avatar
    Join Date
    Nov 2002
    Location
    Phildelphia, PA
    Posts
    1,146
    Another good reason for private members of a class is passwords. You can have a function that verifies if the user entered the correct password without anyone else knowing what the password is.
    FAQ

    "The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." -- Joseph Weizenbaum.

    "If you cannot grok the overall structure of a program while taking a shower, you are not ready to code it." -- Richard Pattis.

  10. #10
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Just remember that like all things that may sound too good to be true, encapsulation isn't a guarantee it is just a hurdle. There is nothing that stops me from writing a class exactly the same as yours with public access on everything and casting your class to mine.

    Example
    Code:
    class Password {
    public:
        Password() { }
    
    private:
        std::string password;
    };
    
    
    class Evil {
    public:
        Evil() { }
    
        std::string password;
    };
    Though this example makes it look easier than it actually is you get the idea. My point is that if someone knows where the memory offset for your password is in the class, they don't need any public access they can just use pointer arithmetic.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 04-11-2003, 07:37 AM