Back to basics: encapsulate a set

In the past, when I learned object-oriented, I learned that it has three features:

• Encapsulation
• Inheritance
• Polymorphism

Java encapsulation is implemented by providing the accesser Method for Private Members, that is, the getter and setter methods that are generally known. This encapsulation is still controversial and beyond the scope of this article. However, when the member variables are of the collection type (Java. util. Collection, java. util. Map, and their subclasses), encapsulation is completely incorrect.

The code I often see is as follows:

1234567891011

public class MyBean {    private Collection collection;     public Collection getCollection() {        return collection;    }     public void setCollection(Collection collection) {        this.collection = collection;    }}

As far as I can see, such code is common, because ORM frameworks such as Hibernate make this design popular. Most of the time, when I put forward my point of view, the advice is to use an immutable design:

1234567891011

public class MyBean {    private Collection collection;     public MyBean(Collection collection) {        this.collection = collection;    }     public Collection getCollection() {        return collection;    }}

Inappropriate Encapsulation

However, when using the collection type, the Java integration type itself is variable, which has not actually changed. Obviously, neither passing in a reference to a collection instance through the constructor nor returning its reference, this is completely not encapsulated. Real encapsulation is possible only when the reference of the collection instance is not (external) retained and no (external) is returned.

123	List list = new ArrayList();MyBean mybean = new MyBean(list);list.add(new Object()); // We changed the encapsulated set outside mybean.

The specific subclass cannot be used.

In addition, the mybean class may need to encapsulate a more specific collection class, such as list or set. The following code snippet shows that it is impossible to pass in a set instance.

1234567891011

public class MyBean {    private List collection;     public List getCollection() {        return collection;    }     public void setCollection(List collection) {        this.collection = collection;    }}

You cannot select a specific implementation

From the above point of view, we naturally think that we will not be able to use (maybe for more efficient) self-defined classes, such as the fastarraylist of Apache commons.

Implementation Suggestions

The following code is the starting point of true encapsulation.

1234567891011

public class MyBean {    private List collection = new ArrayList();     public MyBean(Collection collection) {        this.collection.addAll(collection);    }     public Collection getCollection() {        return Collections.unmodifiableList(collection);    }}

This method solves the following problems:

1. The reference of the collection instance is not passed in from the constructor, so it is impossible to change the instance outside the instance.
2. Due to full isolation, You can freely select the implementation of the Set, leaving room for modification.
3. The reference of the encapsulated collection instance cannot be obtained through the getter accessor method.

Note: For readability, the previous code snippets do not use generics. Please add it in actual use.

Collection

Back to basics: encapsulate a set