A smart setter? Good idea or bad idea?
In the GWT solution. (so this is java code that is then compiled to javascript). There are of course several classes.
Is it a good idea to do a setter check for Null on a String field?
something like that
public void setSomeField(String someField){
if (null != someField)
this.someField = someField;
else
this.someField = String.Empty;
}
Is this a good or bad idea? On the one hand, this will make coding easier since I will not check for null, on the other hand, it will make me probably forget that I have to do this for other strings.
Thoughts? thanks
a source to share
I say that if this kind of logic is needed in your application, then the setter is the place to put it. The main reason why wrapping get / set around a private var is to set logic around access.
To answer the default or non-default question: In my application this caused the property set to return to string for empty display reasons. While people might argue that the view should then cover these possibilities and check for zeros and show nothing, there was a lot of bloat across the pages to check every property.
This is why I started implementing SafeXX properties. So let's say that I had "myObj.Name" which could have been null, there would also be a property "myObj.SafeName" which caught null in the getter and returned a string. A little naming convention makes it clear that it is not a normal recipient.
a source to share
Here's something to consider. Do you expect this unit test to pass or fail ?:
yourClass.setSomeField(null);
assertNull(yourClass.getSomeField());
If you change the null to an empty string and return it in getSomeField, then the client has to check two conditions when testing ... String and null String. Never mind, but what happens if you have twenty String properties in a class ... you are probably better off trying to be consistent among all the setters, and if you don't, the reason should be more obvious than just the documentation saying so.
There are certain conventions around getters and setters; certain expectations. If I call a setter on an object, I usually expect the getter to return what I set. I don't expect it to return some idea of what I went through, which is more convenient for the class to work internally. I don't care about inner classes and I don't want to.
a source to share
If the value null
really needs to be changed to ""
for a good reason (for example it might mean "I don't care", but the default might be ""
), go for it (but document it).
Otherwise, for example if you just caught it NullPointerException
and are trying to fix it this way, don't do it. If callers use explicitly invalid values, this exception should be raised as soon as possible so that the caller notices the problem and fixes it before it bubbles up to a catastrophic, unexplained error in a likely completely unrelated component.
a source to share
In general, it is not a good idea to check for null values, because the caller (whoever invokes the setter) might actually want to set the value to null.
Suppose you are asking for 'someField':
select * from ... where someField is null
If you set it as an empty string, the above request will fail.
a source to share
It's hard to answer. At first glance, it seems like the usage is better because you don't have to constantly check for null. But you lose the quality of the zero value, which means nothing is assigned. If you are doing String.Empty you already have ambiguity if someone gave you the String.Empty as parameter. Maybe it doesn't matter.
I personally (if at all) would not do this to a setter. Inside your class, null must have a value. If you are for convenience, getter
return (this.someField != null) ? this.someField: String.Empty;
will do. You will be holding zero internally to deal with, but the outside has a more convenient method.
In general and personally, I would not do that. It looks good at first and complicates things a lot in later times.
a source to share