Accede al campo privado de otro objeto en la misma clase

class Person { private BankAccount account; Person(BankAccount account) { this.account = account; } public Person someMethod(Person person) { //Why accessing private field is possible? BankAccount a = person.account; } } 

Por favor, olvídate del diseño. Sé que OOP especifica que los objetos privados son privados para la clase. Mi pregunta es, ¿por qué se diseñó OOP de modo que los campos privados tengan acceso a nivel de clase y no acceso a nivel de objeto ?

También estoy un poco curioso con la respuesta.

La respuesta más satisfactoria que encuentro es de Artemix en otra publicación aquí (estoy renombrando la clase AClass con Person): ¿Por qué tienen modificadores de acceso a nivel de clase en lugar de nivel de objeto?

El modificador privado aplica el principio de encapsulación.

La idea es que el ‘mundo exterior’ no debería hacer cambios a los procesos internos de la persona porque la implementación de la persona puede cambiar con el tiempo (y tendría que cambiar todo el mundo exterior para corregir las diferencias en la implementación, lo cual es casi imposible).

Cuando la instancia de la persona accede a las funciones internas de otra instancia de persona, puede estar seguro de que ambas instancias siempre conocen los detalles de la implementación de la persona. Si se cambia la lógica de los procesos internos a Persona, todo lo que tiene que hacer es cambiar el código de Persona.

EDITAR: Por favor, vota la respuesta de Artemix. Solo estoy copiando y pegando.

Consulte la Especificación del lenguaje Java, Sección 6.6.1. Determinar la accesibilidad

Afirma

De lo contrario, si el miembro o el constructor se declara private , se permite el acceso si y solo si ocurre dentro del cuerpo de la clase de nivel superior (§7.6) que incluye la statement del miembro o constructor.

Haga clic en el enlace de arriba para más detalles. Entonces la respuesta es: porque James Gosling y los otros autores de Java decidieron que era así.

Buena pregunta. Parece que el modificador de acceso a nivel de objeto haría cumplir aún más el principio de encapsulación.

Pero en realidad es al revés. Tomemos un ejemplo. Supongamos que quiere copiar profundamente un objeto en un constructor, si no puede acceder a los miembros privados de ese objeto. Entonces, la única forma posible es agregar algunos accesos públicos a todos los miembros privados. Esto hará que tus objetos estén desnudos en todas las otras partes del sistema.

Entonces, la encapsulación no significa estar cerrado a todo el rest del mundo. Significa ser selectivo sobre a quién quieres ser abierto.

Esto funciona porque estás en la class Person : se permite que una clase toque dentro de su propio tipo de clase. Esto realmente ayuda cuando desea escribir un constructor de copia, por ejemplo:

 class A { private: int x; int y; public: A(int a, int b) x(a), y(b) {} A(A a) { x = ax; y = yx; } }; 

O si queremos escribir operator+ y operator- para nuestra gran clase numérica.

Porque el modificador de acceso private hace visible solo dentro de la clase . Este método todavía está EN la clase .

el campo private es accesible en la clase / objeto en el que se declara el campo. Es privado para otras clases / objetos fuera del que está ubicado en.

Con el concepto de reflexión en Java es posible modificar campos y métodos privados

Modificando metodos y campos privados con Refleccion en Java

Lo primero que tenemos que entender es que todo lo que tenemos que hacer es seguir los principios UOP, por lo que encapsular es decir, envolver datos dentro del paquete (es decir, clase) y representar todos los datos como Objeto y de fácil acceso. entonces si hacemos campo como no privado de lo que se accede indivisualmente. y resulta en un mal paratice

Solo mis 2 centavos sobre la pregunta de por qué la semántica de la visibilidad privada en Java es nivel de clase en lugar de nivel de objeto.

Diría que la conveniencia parece ser la clave aquí. De hecho, una visibilidad privada a nivel de objeto habría obligado a exponer los métodos a otras clases (por ejemplo, en el mismo paquete) en el escenario ilustrado por el OP.

En verdad, no pude inventar ni encontrar un ejemplo que muestre que la visibilidad a nivel de clase privada (como la ofrecida por Java) crea problemas en comparación con la visibilidad a nivel de objeto-privado.

Dicho esto, los lenguajes de progtwigción con un sistema más preciso de políticas de visibilidad pueden permitirse tanto la visibilidad de los objetos a nivel de objeto como a nivel de clase.

Por ejemplo, Eiffel , ofrece exportación selectiva: puede exportar cualquier función de clase a cualquier clase de su elección, desde {NONE} (object-private) a {ANY} (el equivalente de public, y también la predeterminada), a {PERSON} (clase privada, vea el ejemplo de OP), a grupos específicos de clases {PERSON, BANK}.

También es interesante observar que en Eiffel no es necesario hacer un atributo privado y escribir un getter para evitar que otras clases se le asignen. Los atributos públicos en Eiffel son accesibles por defecto en modo de solo lectura, por lo que no necesita un getter solo para devolver su valor.

Por supuesto, todavía necesita un colocador para establecer un atributo, pero puede ocultarlo definiéndolo como “asignador” para ese atributo. Esto le permite, si lo desea, usar el operador de asignación más conveniente en lugar de la invocación del instalador.

Privado en Java es el acceso de nivel de clase que escribió. Scala también tiene un objeto privado escrito como private[this] y otras varias formas detalladas aquí http://alvinalexander.com/scala/how-to-control-scala-method-scope-object-private-package

Lo más probable es que el acceso privado a nivel de clase en Java se considerara suficiente y esté en sintonía con lo que tenía C ++ en ese momento.

Supongo que esto fue suficiente en Java porque una clase se escribió en un solo archivo por lo que un autor podría decidir acceder a miembros entre diferentes instancias si realmente quisiera. En Scala puedes heredar el comportamiento de múltiples rasgos y esto puede cambiar el juego.