java – Why can different objects of the same class access each other's private fields?

Question:

Today while taking a course on Udacity (Intro to Java Programming) I thought about this in the Update the class Person exercise (Lesson 3 29/45).

In object-oriented modeling we have the concept of encapsulation (hide implementation) which has no direct relation to protection, but noting one of the purposes of OOP which is to provide a model closer to the organization in the real world, because João can read the "thoughts " from Mary and not ask her?

Class example

class Pessoa {
    // Pensamentos sao privados
    private List<String> pensamentos;
    
    public void lePensamentos(Pessoa outraPessoa) {
         // Por que uma pessoa pode ler os pensamentos de outra pessoa?
         System.out.println(outraPessoa.pensamentos);
    }
}

Example of "Improper" Access to Another Object's Thoughts

Pessoa joao = new Pessoa();
Pessoa maria = new Pessoa();

//João é um objeto em um mundo virtual que representa uma pessoa e seu comportamento deve ser como esperado no mundo real!
//João está curioso para saber o que Maria está pensando então ele chama um método para acabar com sua curiosidade
maria.fazPergunta("O que você está pensando Maria?");

//João percebe que ela não quis responder e achou uma solução! Acessar diretamente seus pensamentos (superpoderes!)
joao.lePensamentos(maria); // isso funciona!

Does the Java language offer any protection features in this regard? Do we have the capability in Java to isolate parts of memory for security reasons? (This question is just for reflection or extra comment)

Clarifications

  1. The example demonstrates situations in which joão (instance) accesses attributes/fields of Mary that should be private only to her.
  2. The word "private" is more in another context than access modifiers in Java, here I put this word as if it were "something private" that only the instance should have direct access to (think of other attributes as an attribute that holds the " password" from someone, etc.).

That's why I asked the question if in Java we have the ability to isolate parts of memory for security reasons.

Answer:

The example question does not show what was asked.

TL;DR

The simple answer to the question is why the language designers wanted it that way and specified it . C++ did it like that, C# too.

Justification

One justification for opting for this is that the compiler is analyzing code that is not executing. He doesn't look at objects, he just looks at what's there in the class. It has no way of guaranteeing that the object that is there is a different object from the current one. It could be the current one.

Of course, you could adopt a convention that if the object doesn't come with the implicit this parameter, which every instance method has, then it should be considered a different object than the current one. But that would complicate some usage patterns. What it's getting may not even be the object of this class concretely, but rather an instance of a derivative.

A good example

How would you do an equals() between two objects of the same class, one of which is the implicit this parameter and the other could be an explicit parameter that ? It is common for the equality method to access private members to check equality.

public boolean equals(Pessoa that) {
    return this.nome.equals(that.nome); //considero que nome é privado
}

I put it on GitHub for future reference .

Then you must ask yourself what would be the gain of blocking this. The private member is not a data access protection mechanism. It's just a way to make it easier for the code not to see members that depend on implementation detail, it's not something that will provide security.

encapsulation

I don't like the definition given in the question. For me, from what I understand in everything I've studied, encapsulation is putting everything in a single capsule, everything that refers to that as one thing. This ends up creating an abstraction, but hiding the implementation detail itself is something else. So I'm going to talk more about abstraction than encapsulation here, although they're quite related (I could talk about information hiding ).

If the implementation detail changes, it was the class itself that changed. All code in the class should be aware of the change. The engine does not want to save the programmer from inadvertently making any changes to the class, otherwise it will make the code too rigid. This only exists to prevent external access to the class within the normal range. This access is internal.

It is used for encapsulation, which refers to the class and not the object. Any object of this class is "trusted" from a code point of view.

Of course, some language may give you the option to restrict this, after all it has its uses, as Scala does (see Anthony Accioly's comment).

Conclusion

So understand that it is not to protect access to the object , it is to ensure internal visibility in the class . It's not a security mechanism, it's just conceptual. Remember that any object can be accessed wherever you want by various techniques, more or less sophisticated, that bypass the compiler, for example with reflection.

Post Views: 0
Scroll to Top