comments? bean with "getter" + "1-arg setter returning input value" + "no-arg setter" per field
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Christopher_Koenigsberg
Posted On:   Thursday, May 9, 2002 12:47 PM

Consider this variation, on the usual "bean field with getter and setter" design pattern/convention. I don't trust methods that return no values, not if they are doing something important, and not if I have a "plan B" to take if they fail, but I don't want the extra overhead of needing to throw and catch an exception in the case of failure: /** * A class to be treated as a "bean", maybe * added to an HttpServletRequest under an * Attribute, for a Struts-based application, * etc. * @author Chris Koenigsberg */ public class MyClass extends MyOtherClass { /** * A member field, just as a trivial example, * to show how I use 2 "setter&   More>>

Consider this variation, on the usual "bean field with getter and setter" design pattern/convention. I don't trust methods that return no values, not if they are doing something important, and not if I have a "plan B" to take if they fail, but I don't want the extra overhead of needing to throw and catch an exception in the case of failure:



			
/**
* A class to be treated as a "bean", maybe
* added to an HttpServletRequest under an
* Attribute, for a Struts-based application,
* etc.
* @author Chris Koenigsberg
*/
public class MyClass extends MyOtherClass {

/**
* A member field, just as a trivial example,
* to show how I use 2 "setter" method
* signatures, instead of 1.
*/
private String myfield = null;

/**
* Initial default value for {@link #myfield}
*/
static final String DEF_MYFIELD = "foo";

/**
* A very, very bad value, to be avoided
* (don't let {@link #myfield} be set to
* this value) -- this is a trivial example,
* but suppose the semantics of
* {@link #myfield} were
* more involved, with a database and other
* dependent DAO helper objects etc.).
*/
static final String DEF_OHNO_BADFIELDVAL = "notthis";

/**
* The traditional bean "getter" but
* with industrial-strength safety checking.
*/
public String getMyfield() {
if (null == this.myfield) {
return null;
} else {
// Defensive copy, per Josh Bloch's
// "Effective Java"
return new String(this.myfield);
} // end getMyfield()

/**
* Now, a variation on the traditional "Setter".
* Note that you can use this just like the usual
* setter, by simply ignoring the return value.
* @param String containing new value for
* {@link #myfield}.
* @return The input, if successful; otherwise, null.
*/
public String setMyfield(String infield) {
if (null == infield) {
this.myfield = null; // suppose null is OK
} else if (! infield.equals(DEF_OHNO_BADFIELDVAL)) {
// Defensive copy, per Josh Bloch's
// "Effective Java"
this.myfield = new String(infield);
return infield; // indicate success with return
} else { // bad, do not want to set myfield
return null; // indicate failure with null return
}
} // end setMyfield(String)

/**
* A second "setter" but taking no args,
* will re-set the {@link #myfield} to
* an internally known default initial value.
* @see #setMyfield(String)
*/
public void setMyfield() {
this.setMyfield(DEF_MYFIELD);
} // end setMyfield()

/**
* Now I can have a standard reset()
* method in all my bean classes, using
* the no-arg "setters" to cleanly
* set all default values.
*/
public void reset() {
this.setMyfield();
super.reset();
}

/**
* Default no-arg constructor for MyClass
* Uses the single-arg copy constructor
* @see #MyClass(MyClass)
*/
public void MyClass() {
this(null);
} // end MyClass() constructor

/**
* Copy constructor, for MyClass
*
*/
public void MyClass(MyClass inmyclass) {
super(inmyclass);
if (null != inmyclass) {
this.setMyfield(inmyclass.getMyfield);
} else {
this.reset();
}
} // end MyClass(MyClass) copy constructor

} // end MyClass


I've been following this strategy/pattern in my code recently (assume superclass MyOtherClass has similar
getter/setter-1-arg/setter-no-arg, reset(), and copy constructor, and I have a whole hierarchy of
similar objects) and I would like some comments.



Typically when you have a "bean" with a "getter" and "setter" pair of methods for a field, the convention is that the "setter" has void return.



I've been writing mine so there is a trio instead of a duo, of methods per field -- a "getter", a "setter" taking an arg and returning the arg if successful, otherwise returning null , and finally, another "setter" signature with no arguments -- this last one has a void return, "knows" what the "default" should be for the field
(so outside callers can call it, to reset the field,
without needing to know
what the particular default should be), and calls the regular "setter" with the default value of the arg.



This way I can choose to ignore the return value of the 1-arg "setter", and thus it behaves just like the usual standard "setter", but if it is appropriate in the calling method, I can check whether the return value is equal to the input arg, to know if the operation succeeded or not. I am assuming here that there was nothing catastrophic enough to throw an exception, just something didn't succeed, to let the caller know to take its "plan B" alternative (e.g. this is only useful in a caller where there IS a "plan B", if the "setter" fails).

   <<Less

Re: comments? bean with "getter" + "1-arg setter returning input value" + "no-arg setter" per field

Posted By:   AlessandroA_Garbagnati  
Posted On:   Thursday, May 9, 2002 02:34 PM

Christopher,

Is an interesting thing...

But I was thinking that in your setter, you are returning the argument you have passed to the method, in order to check if it has succeded in setting the value.

Isn't easier and maybe (just maybe) more elegant, to throw an exception if your setter didn't work for any reason?
About | Sitemap | Contact