Broken JavaBeans due to pass-by-reference expectation
I ran into a problem while working with a procedure that maps POJO properties from one Java object to another. The code assumes that each object’s ‘get’ method returns a direct reference to some internal property. Therefore, the code doesn’t bother to call the POJO’s ’set’ method after it manipulates the retrieved object.
Example 1:
public class pojo1{
private List list1;
private List getList1(){
return list1;
}
private void setList1(List list){
list1 = list;
}
}
The procedure would call pojo1.getList1(), manipulate objects in the List, assume that the state of pojo1 has been updated, therefore not bother to call the pojo1.setList1(List) method.
This is blatantly anti-OO, as the code is making assumptions about the internal implementation of the object.
This code was working fine, until I sent it a JavaBean whose implementation details did not correspond 1 to 1 to the available ‘get’ methods.
Example 2:
public class pojo2{
private List list1;
private List getList1(){
List subList = new ArrayList();
//Iterate over list1
//build subList with only certain elements of list 1
//return subList
}
private List getList2(){
List subList = new ArrayList();
//Iterate over list1
//build subList with only certain elements of list 2
//return subList
}
}
The code in example 2 will fail, because the procedure manipulating the data would not be working on the actual data abstracted by the JavaBean.
When working with JavaBeans it is safer to assume that values are being passed by value and to explicitly call ’set’ methods if that data needs to be changed.
A better idea is to avoid using so many getter/setter methods altogether as advanced in this JavaWorld Article. It makes some fine points about the dangers that procedural programmers make with their usage of JavaBeans, but I think it leans a little bit too heavily towards the ‘purist’ camp. However it is accurate in telling how many people know the bare minimum when it comes to such an important aspect of Java programming.
When returning read-only lists it is always wise to pass them through Collections.unmodifiableList(); of course this is only really safe if all object in the list are immutable, too.
Most of the time an iterator will do, so nobody is tempted to call add on it.
When I want to provide “property-style” access I define a function list1() or whatever the name of the (pseudo)-member is. The effort to do so is not negligable and most of the time all but justified.
Comment by Carsten Saager — July 11, 2006 @ 4:49 pm