Is JavaBeans a good example of encapsulation?

Question

I'm trying to understand if JavaBeans is a good example of encapsulation. In my view, it's not as usually all the internal state is exposed through getters and setters.

A simple example is

public class Test {
    private List<String> names = new ArrayList<String>();

    public List<String> getNames() {
        return names;
    }

    public void setNames(List<String> names) {
        this.names = names;
    }
}

This follows the JavaBeans standard but it leaks the implementation. For example a user could call test.getNames().clear().

Am I missing something?

Answer 1

Encapsulation is an overloaded expression, so let's define it first. According to Wikipedia encapsulation refers to two concepts:

In a programming language encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

1. A language mechanism for restricting access to some of the object's components.

2. A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

I would say that your typical JavaBeans class fulfills the second definition but almost never the first, so I guess the JavaBeans standard is not a good example of that particular notion of encapsulation.

---

Maybe slightly off topic, but explaining why something that starts with class in your code is not necessarily always a class in the more abstract sense. I found a nice definition of class and data structure in Clean Code. Unfortunately I don't have the book here, so I need to recite from the top of my head:

• A class encapsulates its state, only offering sensible methods and exposing state only where it is necessary.
• A data structure fully exposes its state, not trying to hide anything from the outside world

A class implemented according to the JavaBeans standard would be a data structure according to the definition above. That maybe explains why it is a class in code but actually not a class that fulfills encapsulation.

Answer 2

You're right. This is not a good example, and in fact code checkers like e.g. FindBugs will explicitly flag this ("Object exposes implementation by returning a reference to mutable field"). It's not quite as bad as public fields - a getter/setter implementation might one day be replaced by an implementation that does more logic than now, e.g. validation, logging etc., and then clients would receive the benefit of that without being recompiled, but even that won't stop people from relying on the semantics of getNames() being mutable.

A simple, good example of encapsulation is Collections.sort(). Decades of accumulated knowledge about performance and time/space trade-offs, sophisticated algorithms that the majority of programmers ould probably get subtly wrong if they had to write them themselves... and it's all yours for the price of one method call! Strive to emulate sort(), not getNames() in your code.

Answer 3

usually all the internal state is exposed through getters and setters.

That may be the most common case, but usually the point of encapsulation is "provide a public interface behind which we can change things as needed" rather than "protect the implementation details like they were your firstborn sitting on a potty made of solid gold".

If it turns out the internal state has to be protected against manipulation, you can easily change the getter to return a defensive copy or a read-only wrapper.

And note that the real point of the JavaBeans standard is that the getter and setter don't necessarily access a private field - they can just as well convert to and from a field in a different format, you can have only a getter for a derived read-only property, or whatever you can imagine.

So I#d say that actually yes, the Java Beans standard is a good example for encapsulation, even though your typical JavaBean may not be.