Do objects encapsulate data so that not even other instances of the same class can access the data?

Asked 27/4, 2009 at 5:55 Answered 27/4, 2009 at 9:45

In Java,

Do objects encapsulate data so that not even other instances of the same class can access the data? Only when the keyword "private" is used? What are "accessor methods" in Java - methods like getName()?

Thanks

Breakdown answered 27/4, 2009 at 5:55 Comment(0)

I don't tend to think of it in terms of one object having access to another, but rather what code has access to what data within an object.

In Java (and C#, btw) code within a class has access to the private members of any object of the same class. Then you've got package/assembly access and public access.

The tricky one is protected access, which is sort of access to code in subclasses - but it depends on the target object: you're only allowed to access protected members of an object if it's an instance of the same type as the location of the code, or some subclass - even if it's being exposed by a parent class. So for instance, suppose you had:

class Parent
{
    protected int x;
}

class Child1 extends Parent
class Child2 extends Parent
class Grandchild extends Child1

Then within the Child1 code, you can access Parent.x only for objects which are known (at compile-time) to be instances of Child1 or Grandchild. You couldn't, for instance, use new Parent().x or new Child2().x.

Inextensible answered 27/4, 2009 at 6:4 Comment(0)

No, private fields can be accessed even from other instances (within a method of the same class).

They cannot be accessed from subclasses, however, not even within the same instance.

You provide getter methods to allow "outside" code to access fields in your class. Since it is up to you what getters you provide, how visible you make them, and how they are implemented, you can exercise a lot of control as to who can access the data and how.

Note that there does not really need to be a name field if there is a getName: it is entirely up to the implementation of the getter where that data comes from.

Even if the getter (or setter) just wraps a private field, it is good style to have these setters and getters (as opposed to allowing direct field access).

Complainant answered 27/4, 2009 at 5:58 Comment(0)

getName() should return the name (wheather field or some other "thing").

Ferroconcrete answered 27/4, 2009 at 5:59 Comment(1)

Well, it should return the name. Whether that's held in a field called name or whether it's derived from some other object etc is an implementation detail. – Inextensible 27/4, 2009 at 6:5

Even if a field/method is 'private', it can still be accessed/invoked via reflection unless you install a custom security manager that disallows that.

Disabled answered 27/4, 2009 at 6:12 Comment(2)

You could also access the fields through JNI. Who cares? (Also, no need for the security manager to be custom.) – Grow 27/4, 2009 at 8:23

Well, yes. That's one of the reasons to avoid reflection if at all possible. – Incandescent 27/4, 2009 at 10:50

The idea of encapsulation is to allow implementations of different units to vary freely. Although we talk of objects, for encapsulation we really mean a unit of code. In class-based languages, the unit of code is usually the [outer] class.

It also happens that binary operations (such as equals) become daft without access within the same class. So private means private to the [outer] class, not private to the same class within the same instance.

Accessor methods generally indicate bad design on anything but simple value objects (getters only). Objects should have behaviour, rather than just be a dumb collection of data. Move code that would be on the outside using getters to a method that is meaningful on the object. Hand on heart, 99% of the time getters just return a field value. There is relatively little value in making a field private if you are going to add a getter and setter.

Grow answered 27/4, 2009 at 8:35 Comment(0)

What are "accessor methods" in Java - methods like getName()?

Yes - getFoo() and setFoo() are accessor methods for a "property" named foo - this is part of the JavaBeans specification. The reason why these are preferred over public fields is that they allow you to have only a getter (making the property read only), do additional bookkeeping (like calculating derived fields) and validation of set values (throwing e.g. a PropertyVetoException when the value is not acceptable).

The whole thing was originally intended to be used with GUI tools that would allow you to graphically configure and combine JavaBeans in order to "build applications". This turned out to be largely a pipe dream, but the concept of JavaBeans and properties has turned out to be useful for regular coding and become wide-spread.

Many people misunderstand the concept and believe that "encapsulation" just means writing setters and getters for private properties instead of making them public - and then rightfully consider that idiotic. Encapsulation means not exposing the inner workings of a class at all except in tightly controlled ways. In good OO design, you should not have too many get methods and very few set methods in a class.