can I define setter method to return this rather than void?
Like:
ClassA setItem1() {
return this;
}
ClassA setItem2() {
return this;
}
then I can use new ClassA().setItem1().setItem2()
Setters cannot return values. While returning a value from a setter does not produce an error, the returned value is being ignored. Therefore, returning a value from a setter is either unnecessary or a possible error, since the returned value cannot be used.
Conventionally, setters should not return a value. Therefore, it needs to be a void method, because you're not returning anything from it (just initializing the instance variables). Getters, on the other hand, does return a value.
The private getter/setter methods provide a place for adding extra behavior or error checking code. They can provide a place for logging state changes or access to the fields. They can provide a place for adding your debug code while testing.
JavaBeans are classes that encapsulate many objects into a single object (the bean). It is a java class that should follow following conventions: Must implement Serializable. It should have a public no-arg constructor.
There is a lot of misunderstanding about JavaBeans spec.
The main reason for it's existence is the unified Java "component" model. It's a way to interact programatically with a Java Object using Reflection. The API itself is named JavaBeans Introspection. Please, take a look at example usages and You will know a lot more than an average Java programmer does.
Introspection API can be used to manipulate GUI elements in an unified manner. Your component exposes it's properties as a pairs of getters and setters so that they could be discovered and manipulated at run-time on a GUI builder's property sheet.
So, mixing fluent APIs and JavaBeans Spec in my opinion is a no-go. That's two completely unrelated concepts and can disrupt each other. JavaBeans Introspection might not work when method signature differs (return type).
Take a look at this example (taken from linked tutorial):
public class SimpleBean
{
private final String name = "SimpleBean";
private int size;
public String getName()
{
return this.name;
}
public int getSize()
{
return this.size;
}
public void setSize( int size )
{
this.size = size;
}
public static void main( String[] args )
throws IntrospectionException
{
BeanInfo info = Introspector.getBeanInfo( SimpleBean.class );
for ( PropertyDescriptor pd : info.getPropertyDescriptors() )
System.out.println( pd.getName() );
}
}
This example creates a non-visual bean and displays following properties derived from the BeanInfo object:
You might want to see what happens when You change void
return type to anything else. I have done so and the result is the same. So, does that mean it's allowed?
I'm afraid no. The JavaBeans spec is quite strict about those method signatures. It just happened that implementation is forgiving. Nonetheless, I'd disadvise mixing fluent interface with JavaBeans. You can't really rely that, if the discovery works now, it will also in future.
But, from the other side - it looks like You don't use JavaBeans to full extent. Only the getters/setters pair of method. It's up to You how You implement and design Your APIs.
The JavaBeans Specification describes a JavaBean as:
A Java Bean is a reusable software component that can be manipulated visually in a builder tool
They are required to provide introspection, customization, events and persistence among other properties (Section 2.1: What is a bean?)
It is common to call a "Java Bean" to a Plain Old Java Object with accessor methods following the JavaBeans Specification (Section 7.1 and 8.3). The truth is that such object could still be far from being compliant with all the requirements.
If the object your are defining in this class is actually a JavaBean then your method must return void according to JavaBean Specification, section 7.1 where accessor methods are described as follows:
void setFoo(PropertyType value); // simple setter
PropertyType getFoo(); // simple getter
The section 8.3 named designed patterns for properties says:
By default, we use design patterns to locate properties by looking for methods of the form:
public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);
In addition, for boolean properties, we allow a getter method to match the pattern:
public boolean is<PropertyName>();
However, if your class is just a POJO then there is nothing wrong with using your method chaining strategy because you are allowed to deviate from the specification since you are not actually building a JavaBean. Not all the classes you define are supposed to be JavaBeans after all, right?
Your might like to take a look at the Oracle JavaBeans Tutorial.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With