About Question enthuware.ocajp.i.v8.2.1107 :

[JuergGogo]

It helps make sure that clients have no accidental dependence on the choice of representation

I'm not english native and I just don't get the sense of that statement. Can somebodey explain the meaning with different words, please.
Thank you.

[admin]

First, you need to understand what is meant by representation. It is how you capture a concept in your class. For example, if you are writing a class that stores a list of Items in an Order, like this -

Code: Select all

public class Order{
   public ArrayList<Item> items;
   public List<Item> getItems(){  return items; }
   public void setItems(List<Item> i){  items =  i; }
}

The above class uses an ArrayList of Items to represents the list of Items in an Order. Now, since the field items is public, any other class or method that gets a reference to Order object, can directly use items field of Order like this -

Code: Select all

public class OrderProcessor{
  public void processOrder(Order o){
     o.items.remove(0);
  }
}

Observe that the processOrder method is able to call any method that is available in ArrayList. So you cannot prevent any one from modifying the items list.

Now, what if you want to prevent others from changing the contents of items List? You may want to change the type of items from ArrayList to may be to some other unmodifiable collection but you can't do that now because other people have coded their classes to directly access the items variable assuming it of type ArrayList. If you change the type now, other code will break i.e fail to compile. This is what is meant by accidental dependence on choice of representation.

If you had made items field private and returned List<Item> from the getItems method, you could have easily changed the internal representations of items from ArrayList to any other class. No other code would break.

HTH,
Paul.

[JamBuckles]

It helps avoiding name clashes as internal variables are not visible outside.

I understand that encapsulation prevents internal variables from being visible outside. However, how does this avoid name clashes?

Code: Select all

class Foo {
    int bar;
}
class Test {
    public static void main(String[] args) {
        Foo foo = new Foo();
        Foo foo2 = new Foo();
        foo.bar = 10;
        foo2.bar = 20;
    }
}

As we can see from above, even without encapsulation there doesn't seem to be any name clash as we can still clearly tell which Foo object each bar belongs to.

Or am I missing something here?

[admin]

There are situations where it can help. For example, what if you subclass a given class and want to have a field with the same name as the one in the super class? If the field in the super class is not private, it will cause confusion in the subclass code. Of course, there are ways to resolve the name clash but it is still considered bad design.

[JamBuckles]

I see, thank you for the quick response.

If the field in the super class is not private, it will cause confusion in the subclass code.

Does the confusion mean confusion to future programmers, or are there cases where it will actually cause compile-time errors / exceptions / unpredictable program behaviours?

[admin]

Confusion for the programmer and thus it is a potential source of bugs.

[JamBuckles]

I see, thank you!