To Bean, Will Bean, Has Bean - JavaBean

One of the 'patterns' Sun introduced for Java was the JavaBean. To be a bean, an object must have:

1. All data private
2. Data accessed by getters and setters only.
3. The get pattern is the data name, capitalised and preceded by 'get'.
4. The set pattern is the data name, capitalised and preceded by 'set'.

Example:

class MyBean
  {
    private String stringData;
    public String getStringData() { return stringData; }
    public String setStringData( String to) { stringData = to; }
  }

 

Waking Up and Smelling the JavaBean JavaBeans are useful in their place, but embracing the pattern as a blanket-fix undermines their usefulness and restricts your options. So weigh up the pros and cons for any given situation, and don't use a JavaBean unless the infrastructure calls for one.

Pro	Con
Data Cop: Java's policy is to act as a police force for your library. Java assumes that all users of your library are criminals who will cheat and abuse the internals and interfaces if they are allowed. By using getters and setters you have more access control over the data than if it were public.	...The Lazy Cop: At best, Java is a terse policeman – at worst, ineffective. Given that Java does not have a concept of friends (except package private), most setters are public. Why put up with the Gestapo marching through your neighborhood, if they don't notice all the theft going on under their noses? Oh, and using the constructor to load rather than having setters is the same as using final for the resulting data.
Choice Without Consequence: When you use getters and setters, you give the library user more freedom to change the internals without being directly affected – data from a database, for example, can be lazy loaded inside the getter or retrieved each time it is called - all without callers of the interface being aware.	...But Don't Get Lazy: While it is poor practice, I have seen many, many developers call a getter repeatedly rather than save it as a local variable. If the class owner changes a getter from retrieving local class instance data to reading a database, the overheads of bad usage practice change from minor to enormous. If you are publishing beans to be used as black boxes (as ActiveX is used for Windows programs), by all means use getters and setters. In all other cases their use is questionable. Sure, the user of a class will need to change their code if they upgrade to a newer version, but this gives them an excellent opportunity to review the code that needs to be changed. If an instance field becomes private they will know to change to an accessory method. Reviewing the related JavaDoc will tell them what is happening so that they can adjust their usage code accordingly. If the process were transparent they would plug in the new class and not even look at the usage.
The Square Peg Fits: Finally, the reason for the bean design is to provide a clear standard for factory methods and non-Java components (such as XML) to be able to access or modify Java internals. Ah, the rich aroma of plug-and-play.	...But Not Always As Well As The Round: When the infrastructure requires a bean, use the bean pattern with setters and getters. When it is not, use other data storage and retrieval patterns. A discussion of these patterns will keep for another day. There are times when you should access the data directly, times it should be copied into a DTO (data transfer object) and times you should use retrieval methods not using the getXXX() pattern.