How does the design of JavaBeans square with information hiding?

Question

Two semesters ago, I had a professor who said:

Some of you have been told to always include setter and getter methods for all private instance variables. I say that this breaks information hiding, and often results in systems where invariants cannot be enforced.

Now, that sounds right to me. But isn't including those kinds of setters/getters a core part of creating JavaBeans? If so, why? If not, what am I misunderstanding about JavaBeans?

Answer 1

It's usually quite simple, you expose setters/getters for the variables you need to make visible externally, and you don't expose setters/getters for variables noone else have any business knowing about.

Answer 2

Your professor is correct. You do not want to blindly create getters and setters for all instance variables. You want to create them where they are required.

If you have a BankAccount class with a balance instance variable, creating getters and setters for it makes sense if you want to be able to check and set the balance.

Even here there is information hiding - in the form of encapsulating the implementation. The getter "double getBalance()" could simply return the value of the underlying instance variable if it is a double, or it could be returning a value derived from a BigDecimal if that is the implementation choice for the variable, or it could be calling a remote web service and returning the result. So, the getter/setter still allows for the implementation to vary and thus does not violate encapsulation (and by extension, neither do JavaBeans).

What JavaBeans do for you is define an interface (getXXX(), setXXX()) for getting and setting "properties", attributes of a class that users would typically want to examine or change. If your class has information that is not considered a "property", there is no need to expose it. For example, let's say the BankAccount class has an instance variable used for validating withdrawals. If the client does not need access or modify this, there is no point in creating a getter or setter for it.

Answer 3

Getters and setters are not required in a Java Bean class. All that's required is that the class must be public, it must have a public no argument constructor and it must implement Serializable. However, in order for variables to be discovered automatically when your bean is used you must provide getters and setters following a standard naming convention (getVarname, setVarname...).

In any case, you want to make externally visible only the variables that have a business being seen outside your class.

Answer 4

You may want to read Why getter and setter methods are evil:

You might object by saying, "But what about JavaBeans?" What about them? You can certainly build JavaBeans without getters and setters. The BeanCustomizer, BeanInfo, and BeanDescriptor classes all exist for exactly this purpose. The JavaBean spec designers threw the getter/setter idiom into the picture because they thought it would be an easy way to quickly make a bean—something you can do while you're learning how to do it right. Unfortunately, nobody did that.

Accessors were created solely as a way to tag certain properties so a UI-builder program or equivalent could identify them. You aren't supposed to call these methods yourself. They exist for an automated tool to use. This tool uses the introspection APIs in the Class class to find the methods and extrapolate the existence of certain properties from the method names. In practice, this introspection-based idiom hasn't worked out. It's made the code vastly too complicated and procedural. Programmers who don't understand data abstraction actually call the accessors, and as a consequence, the code is less maintainable.