Question

Is it necessary for setter methods to have one argument? Usually setter methods accept one argument as the value of a certain property of an Object. What if I want to test first the validity which depends on another argument which is a boolean, if true, validate first, else just set the value.

I am getting the values from clients through ftp server. Sometimes those files contain garbage values. For instance, a phone number like #3432838#9. So before I set the value I need to remove those garbage characters. Can I do it in the setter methods? Is it a valid approach?

Thanks a bunch in advance!

EDIT:

Is this valid:

public void setSomething(String strValue){       if(checkValidity(strValue)){           // set the value       } else {           // set the value to an empty string      }     } 

Answer 1

It is necessary specifically in the java bean framework model, but it s not mandatory in general.

You can have setter with no argument when they are meant to ‘swith’ a value.

void setCheck() 

could for instance be meant to set the ‘check’ boolean attribute to true.

So even if it is not a ‘setter’ in the java bean sense of the term, you can imagine setter used for other purposes.

Plus, according to section 7 of JavaBean specifications, a setter can have more than one argument, for instance for Indexed properties (An indexed property supports a range of values. Whenever the property is read or written you just specify an index to identify which value you want.)

void setter(int index, PropertyType value); // indexed setter void setter(PropertyType values[]); // array setter 

---

In your case, a valid approach would be to add a runtime exception to the signature of our function.
That way you do not put any unnecessary compilation-time exception checking for all of the other classes which are already calling your setter.

Or you could consider your property as a Constrained property and add a non-runtime exception.

Constrained property setter methods are required to support the PropertyVetoException. This documents to the users of the constrained property that attempted updates may be vetoed. So a simple constrained property might look like:

PropertyType getFoo(); void setFoo(PropertyType value) throws PropertyVetoException; 

which allows for VetoableChangeListener to be added if needed.

---

Regarding your snippet, it is ‘valid’ but may not be optimal because (as said in this question):

• Validation should be captured separately from getters or setters in a validation method. That way if the validation needs to be reused across multiple components, it is available.
• It is better to fail fast (hence my proposition to add exception to the setter).