Why does people want use private label here?

[northfly]

when you can do:

you can easily do

class point_t {
pubic:
    double x, y;
}

why do you do:

class point_t {
private:
    double x,y;
public:
    double getX();
    double gety();
    bool changeX(double val);
    bool changeY(double val);
};

for security? why, people can always change x and y through public functions.

And it is clumsy, 4 more functions will consume much more memory and cpu time, right?

[JLBorges]

When I can do:
struct point_t { double x, y ; };

Why do I do:

class point_t {
private:
    double x,y;
public:
    double getX() const ; /* { return x ; } */
    double gety() const ; /* { return y ; } */
    bool changeX(double val); /* { x = val ; } */
    bool changeY(double val); /* { y = val ; } */
};

Because I am extremely stupid.

> why, people can always change x and y through public functions.
> And it is clumsy, 4 more functions will consume much more memory and cpu time, right?

It won't really consume more memory and cpu time (the compiler knows what is going on), but it is clumsy; it introduces mindless verbosity, which is always more expensive in terms of programmer time and programmer memory.


In languages which are C based, there are reasons why we might want to restrict access to something that we have exposed; made programatically visible.

One, we might have identified an invariant which we must maintain for program correctness. For instance:

struct wall_clock
{
       // ....

       private:
           int hour ; // invariant:  must be in [0,23]
           int minute ; // invariant: must be in [0,59]
}; 

Even if the member variables hour and minute are visible to every user, we would want to prevent unrestricted access to them (private) because our design requires that we must ensure that the invariant in maintained at all times.

Two, we might want to change the implementation at some point in future without breaking user code.

struct wall_clock
{
       // ....
       // same interface as earlier

       private:
           int seconds_since_midnight ; // invariant:  must be in [0,24*60*60)
           // but a different implementation 
}; 

Three, we may want (very often we do want) the logical interface to reflect the needs of the user while the implementation details reflect the needs of the implementor. For instance:

struct person
{
    int age_in_years() const ;
    // ....

    private:
        date date_of_birth ;
}; 

If none of these concerns are applicable, a point class with private data is pointless.

[Uk Marine]

In addition, Public members are available anywhere in your program, meaning you could access a class member functions or data members in a different function or a different class, sometimes this might be exactly what you want, however by default the access level is private, meaning that they're only available in that class and can't be accessed anywhere else.

[Stewbond]

We can also use the get/set functions to check validity of inputs:

class Month
{
private: 
    int monthIndex;
public:
    void setMonth(int i) 
    { 
        if (i >= 1 && i <= 12)
            monthIndex = i;
        else
            throw someException();
    }
    int getMonth() { return monthIndex; }
};

Or let's say that we have a class where we can access the squre-root of a label. If we set the value once, but use the square root lots, then it makes sense to only calculate the square-root once.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

// One option class Sqrt { private: double x, sqrtx; public: void setx(double _x) { x = _x; sqrtx = sqrt(_x); } double getx() { return x; } double getsqrt() { // more effecient if we use sqrt(x) // lots and set x a little return sqrtx; } };

// Alternative which may or may not be as efficient class Sqrt { private: double x; public: void setx(double _x) { x = _x; } double getx() { return x; } double getsqrt() { // more efficient if we set x lots // and use sqrt(x) a little return sqrt(x); } };

but yeah, doing just this is rather stupid:

class MyClass
{
private: 
  int x;
public:
  void setx(int val) { x = val; }
  void getx() { return x; }
};

I'd only do that if I had a class with a ton of parameters who had set/get functions already which were actually useful. This would be added for the sake of symmetry only.

[BHX]

I'm surprised no one brought up OOP, data hiding, or encapsulation as to why it is done.

[northfly]

Thank all for all these inputs, really learned something!!!