C++

Forum

 
C++ & Java OOP Access Control Violation: access peer object's private fields

h9uest (157)
I instantiate two objects of one class, and one object accesses and changes private fields of the other object. I believe this violates the private access control. It breaks encapsulation in OOP. However, I find that both C++ and Java seem to allow this "violation". Please enlighten me why this "violation" is allowed!

Sample C++ code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
#include <iostream>
using namespace std;

class Person
{
    private:
        int age;
    public:
        void changeAge(Person & p, int k) // change peer object's private fields
        {
            p.age = k;
        };

        Person(int k)
        {
            age = k;
        };

        void showAge()
        {
            cout << this->age << endl;
        };
};

int main()
{
    Person a(10);
    a.showAge();
    Person b(11);
    b.changeAge(a, 20); // I think the compiler SHOULD generate access violation error
    a.showAge();
    b.showAge();
    return 0;
};



The output is:

1
2
3
 
10
20
11


You may write similar code for Java, and you'll have the same output.

I consulted http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html I understand private fields are visible at the class level. I believe that's probably the only viable reason for this "violation" to take place. (Please add more reasons if you can!)

However, I don't think it makes sense to allow this "violation", because it breaks encapsulation in OOP. The fact that we both are human beings does NOT imply that I can access and modify your private stuff. It's no longer your "private stuff" if I can.

Please enlighten me! Is the "violation" a bug of C++ & Java? If I'm wrong, please let me know!
naraku9333 (2163)
It's not a violation, as you said the visibility is at the class level, as they are the same class type they have the same access.
However, I don't think it makes sense to allow this "violation", because it breaks encapsulation in OOP.
Encapsulation is up to the programmer, while OOP is a big part of c++ but I see no reason the language should force it.
Last edited on
closed account (o1vk4iN6)
You should not need an object in order to use that function. The reason for the semi-colon at the end of a class or struct is because an object can be defined after it, it is meaningless and confusing to have it for a function.

 
 
struct { float x, y; } myStruct;


1
2
3
4
5
6
7
8
9
10
11
12
13
14
 

class Person
{
public:
        static void changeAge(Person & p, int k) // change peer object's private fields
        {
            p.age = k;
        } // semi-colon not needed
};


// use
Person::changeAge(p, k);


If you implement a function in Person it has access to any private variable in Person class. It doesn't matter if it's another Person or not it is still of type Person. Wouldn't make sense if you couldn't do this, you are creating the class, you know what everything does (or you should) so nothing needs to be hidden from you.


The fact that we both are human beings does NOT imply that I can access and modify your private stuff. It's no longer your "private stuff" if I can.


That's not the way to think of it.

Think of the class Person as a surgeon, although he doesn't know you personally he knows what's inside you so it doesn't matter from one person to the next you are still the same inside. So he can do the same surgical procedure on you that he can do on someone else.
Last edited on
viliml (791)
xerzi wrote:
If you implement a function in Person it has access to any private variable in Person class. It doesn't matter if it's another Person or not it is still of type Person. Wouldn't make sense if you couldn't do this, you are creating the class, you know what everything does (or you should) so nothing needs to be hidden from you.

[quote]
The fact that we both are human beings does NOT imply that I can access and modify your private stuff. It's no longer your "private stuff" if I can.


That's not the way to think of it.

Think of the class Person as a surgeon, although he doesn't know you personally he knows what's inside you so it doesn't matter from one person to the next you are still the same inside. So he can do the same surgical procedure on you that he can do on someone else.
[/quote]
Yes, but it's kina weaird that someone lese can change your AGE! I mean, not even you should be able to do that! LOL
rapidcoder (1010)
It *is* a violation of OOP, similar to "friend". Java inherited that from C++. Scala fixed it with private[this] (Scala supports both behaviours).
ne555 (10692)
smalltalk: all members are private, all methods are public.
You can only see your 'self' members. So double dispatch is common.

Yes, but it's kina weaird that someone lese can change your AGE! I mean, not even you should be able to do that!
And you can't, age should be computed in base to date_of_birth that would be constant.
current_year is not yours.
Topic archived. No new replies allowed.