¿Encapsulan los datos los objetos para que ni siquiera otras instancias de la misma clase puedan acceder a los datos? ¿Solo cuando se usa la palabra clave "privada"? ¿Qué son los "métodos de acceso" en Java - métodos como getName()?
Gracias
no tienden a pensar en términos de un objeto tener acceso a otro, sino más bien lo código tiene acceso a qué datos dentro de un objeto.
En Java (y C#, btw) el código dentro de una clase tiene acceso a los miembros privados de cualquier objeto de la misma clase. Luego tiene acceso a paquete/ensamblaje y acceso público.
El asunto difícil es protegido de acceso, que es tipo de acceso al código en las subclases - pero depende del objeto de destino: sólo se permite acceder a los miembros protegidos de un objeto si se trata de una instancia de la misma escriba como la ubicación del código, o alguna subclase, incluso si está siendo expuesto por una clase principal. Así, por ejemplo, supongamos que tiene:
class Parent
{
protected int x;
}
class Child1 extends Parent
class Child2 extends Parent
class Grandchild extends Child1
Luego, dentro del código Child1, puede acceder a Parent.x sólo para los objetos que se conocen (en tiempo de compilación) a haber casos de Child1 o Grandchild. No podría, por ejemplo, usar new Parent().x o new Child2().x.
No, campos privados se puede acceder incluso de otros casos (dentro de un método de la misma clase).
No se puede acceder desde las subclases, sin embargo, ni siquiera dentro de la misma instancia.
Proporciona métodos getter para permitir que el código "externo" acceda a los campos de su clase. Dado que depende de usted lo que obtiene, lo visible que los hace y cómo se implementan, puede ejercer un gran control sobre quién puede acceder a los datos y cómo.
Tenga en cuenta que realmente no es necesario que haya un campo name si hay un getName: depende totalmente de la implementación del captador de donde proceden los datos.
Incluso si el getter (o setter) simplemente envuelve un campo privado, es un buen estilo tener estos setters y getters (en lugar de permitir el acceso directo al campo).
getName() debe devolver el nombre (campo wheather o alguna otra "cosa").
Incluso si un campo/método es 'privado', todavía se puede acceder/invocar a través de la reflexión a menos que instale un administrador de seguridad personalizado que no permita eso.
También puede acceder a los campos a través de JNI. ¿A quien le importa? (Además, no es necesario que el administrador de seguridad sea personalizado.) –
Bueno, sí. Esa es una de las razones para evitar la reflexión si es posible. – sleske
La idea de la encapsulación es permitir que las implementaciones de diferentes unidades varíen libremente. Aunque hablamos de objetos, para la encapsulación realmente queremos decir una unidad de código. En los lenguajes basados en clases, la unidad de código suele ser la clase [externa].
También sucede que las operaciones binarias (como las iguales) se vuelven tontas sin acceso dentro de la misma clase.Así que privado significa privado para la clase [externa], no privado para la misma clase dentro de la misma instancia.
Los métodos de los accesor generalmente indican un mal diseño en cualquier cosa que no sean objetos de valor simple (solo getters). Los objetos deben tener un comportamiento, en lugar de simplemente ser una colección tonta de datos. Mueve el código que estaría afuera utilizando getters a un método que sea significativo para el objeto. De la mano en el corazón, el 99% de las veces los getters simplemente devuelven un valor de campo. Hay relativamente poco valor en hacer un campo privado si va a agregar un getter y un setter.
¿Qué son los "métodos de acceso" en Java - métodos como getName()?
Sí - getFoo() y setFoo() son métodos de acceso para un "propiedad" llamado foo - esto es parte de la especificación JavaBeans. La razón por la cual estos son preferibles a los campos públicos es que le permiten tener solo un getter (haciendo que la propiedad solo sea de lectura), hacer contabilidad adicional (como calcular los campos derivados) y validar los valores establecidos (lanzando, por ejemplo, PropertyVetoException cuando el valor es inaceptable).
Todo el dispositivo se diseñó originalmente para ser utilizado con herramientas de GUI que le permitieran configurar y combinar gráficamente JavaBeans para "crear aplicaciones". Esto resultó ser en gran medida una quimera, pero el concepto de JavaBeans y propiedades ha resultado útil para la codificación regular y se ha generalizado.
Muchas personas malinterpretan el concepto y creen que la "encapsulación" solo significa escribir setters y getters para propiedades privadas en lugar de hacerlas públicas, y luego, con razón, considerar que es una idiotez. La encapsulación significa no exponer el funcionamiento interno de una clase en total excepto en formas estrictamente controladas. En un buen diseño de OO, no debería tener demasiados métodos de obtención y muy pocos métodos establecidos en una clase.
¿Los objetos encapsulan datos de manera que ni siquiera otras instancias de la misma clase puedan acceder a los datos?
Claro, si no está utilizando miembros estáticos.
Extracto de this link:
A veces, usted quiere tener variables que son comunes a todos los objetos. Esto se logra con el modificador estático. Los campos que tienen el modificador estático en su declaración se llaman campos estáticos o variables de clase
Bueno, debería devolver el nombre. Si eso se mantiene en un campo llamado nombre o si se deriva de algún otro objeto, etc. es un detalle de implementación. –