With a Private Modifier, Why Can the Member in Other Objects Be Accessed Directly

With a private modifier, why can the member in other objects be accessed directly?

Good question. The point is that protection in C++ is class level, not object level. So a method being invoked on one object can access private members of any other instance of the same class.

This makes sense if you see the role of protection being to allow encapsulation to ensure that the writer of a class can build a cohesive class, and not have to protect against external code modifying object contents.

Another thought as to the real "why?". Consider how you write almost any copy constructor; you want access to the original's underlying data structure, not its presented interface.

A private variable can be accessed from another object of the same type?

Methods of a class can access its private attributes throughout all class instances, at least in C++.

Can we access private members of another object within a method of a class?

Colloquially, C++'s private is "class-private" and not "object-private".

Scopes are associated with lexical elements of source code, not with run-time entities per se. Moreover, the compiled code has little to no knowledge of the logical entities in the source it was compiled from. For this reason the accessibility is enforced on the level of lexical scopes only. Within the scope of the class, any object of the class's type can have its private members accessed.

Plus, C++ wouldn't be able to work as a whole otherwise. A copy constructor or an assignment operator could not be written if the accessibility was checked on a per-object basis. Those operations need to access the members of the source object in order to initialize/overwrite the target object.

In Java, why are the private data members accessible outside the class if written like this?

Because the method is in the same class, it can access private members of other instances. private only means that only functions in the class can access it, with no restrictions on which object is doing the accessing.

What is the purpose of access modifiers?

The reason becomes more apparent when you have to maintain a larger project. When a method or variable is public, you have to be careful when you make changes to it, because you never know which parts of the codebase rely on its exact behavior.

But when a variable or method is private, you know that it is not used outside of the class. That means there is a lot less code you have to pay attention to when you make changes.

By making class features private and public, you clearly separate the interface to the outside world from the internals. The less you exposes to the outside world, the more freedom you have with what the internal implementation does.

When you, for example, always make variables private and accessed them through getters and setters, you can later change them from a variable to a computed value, and then even later add caching to the computation for performance reasons. When it would be a public variable, you would have to change code everywhere the variable is used. But when you expose it to the outside world through getters and setters, all other code can keep using the class as if nothing had changed.

If we can access private data members using Accessors than why cant we access private methods?

You can access private method via public method. This is sometimes used to wrap complicated private method and expose simpler, public API.

class Delegator {

    private void doPrivateStuff(int param) { ... }

    public void doStuffOnce() {
        doPrivateStuff(1);
    }

    public void doStuffIfConditionIsMet() {
        if(condition) {
            doPrivateStuff(1);
        }
    }
}

You can also access private methods using reflection.
http://tutorials.jenkov.com/java-reflection/private-fields-and-methods.html

Clarification of private access modifier

This is the common misconception that private fields are accessible only by the same instance.

Actually, private fields are private within that class, and not for an instance. So any instance of that class can access private field when in that class.

From JLS - Section 6.6.1:

Otherwise, if the member or constructor is declared private, then access is permitted if and only if it occurs within the body of the top level class (§7.6) that encloses the declaration of the member or constructor.

Emphasis mine.

Access private field of another object in same class

I am also a bit curious with the answer.

The most satisfying answer that I find is from Artemix in another post here (I'm renaming the AClass with Person class):
Why have class-level access modifiers instead of object-level?

The private modifier enforces Encapsulation principle.

The idea is that 'outer world' should not make changes to Person internal processes because Person implementation may change over time (and you would have to change the whole outer world to fix the differences in implementation - which is nearly to impossible).

When instance of Person accesses internals of other Person instance - you can be sure that both instances always know the details of implementation of Person. If the logic of internal to Person processes is changed - all you have to do is change the code of Person.

EDIT:
Please vote Artemix' answer. I'm just copy-pasting it.

Public class requires public members (when accessing members)?

Expanded from the comments section

Access modifiers only apply to the things they directly modify. Thus, public on a class only affects the visibility of the class -- not the visibility of any of its members. Thus, you can provide public members for a package-private class, which could be useful if you have an abstract class you want to keep hidden from the public API.

In addition, the lack of a visibility modifier is already defined to mean package-private visibility. Thus, it cannot be used to mean "same as class". As for why the language is designed that way, the best I could come up with is that it might have seemed like a good balance between limiting visibility to the outside world while still allowing different top-level classes to interact.

---

Related Topics