Re: sholud getters/ setters be inside interfaces?
Top posting corrected...
Elhanan wrote:
Daniel Pitts wrote:
Elhanan wrote:
hi..
i'm just wondering should getters and setters (of at least simple
types) be included in an inteface? or just inside a class or abstract
class?
is this ok?
public interface person
String getName();
void setName(String name);
int getId();
void setId(int id);
Read "Why getters and setters are evil"
(http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1)
and then decide.
oh i read him, but he is way too extreme, if i follow him, there will
no java bean spec, tools like hibernate, spring, and jstl..
Actually, if you read the article more carefully, he does talk about
the javabean spec (which was intended to be used in automated tools,
such as hibernate and spring), and how most programmers abuse it.
In any case, I was discussing this "extreme" point of view with a
friend of mine, and we discovered that it makes sense for some classes
of objects to have observable properties, but novice OO programmers
tend to expose too much through getters/setters.
An example. Say I have a Robot class. A Robot has its internal state,
which is mostly hidden from the world. It makes sense that you can
query the location of a Robot, so that is one of its observable
properties. A gettter is appropriate for this. The state of the
robots program (assuming there isn't a debugger attached) is a hidden
state (implementation detail).
The article also talks about this concept, but in different words.
Without saying "primitive obsession", he describes the solution to that
bad smell. If you absolutely must return a value property, it should
be returned by interface, not by primitive.
If you get used to refactoring code, you'll realize that you can avoide
a lot of indecent exposure just by moving a method to the class it
probably belongs in.