Whether private getter methods is Evil?
Hi!
I was wondering whether it is bad or good to use private getter methods in a class rather than directly accessing private fields?
For instance, I have a getter method for each Swig component used in my program:
private JButton run;
private JButton getRun(){
if (run !=null){
return run;
}
run =new JButton("Run");
run.setToolTipText("Run");
run.setIcon(new ImageIcon(ResourceHelper.getImageResource("run.png")));
run.setEnabled(false);
run.addActionListener(new ActionListener(){
publicvoid actionPerformed(ActionEvent event){
MessageDialog.showPleaseWait(TestRunnerUI.this,
"creating logger",new Runnable(){
publicvoid run(){
// bla bla bla
}
}
);
}
});
return run;
}
And so for each swing component....
But for example I have such a method:
privatevoid disconnect(){
mRunner =null;
mLogger =null;
log.log(Logger.INFO,"disconnected");
tree.setModel(defaultModel);
tree.setEnabled(true);
save.setEnabled(false);
saveAs.setEnabled(false);
load.setEnabled(false);
options.setEnabled(false);
run.setEnabled(false);
breakTests.setEnabled(false);
connect.setEnabled(true);
disconnect.setEnabled(false);
// ...
}
which changes properties of a lot of components...
I don't know whether I should use there private getter methods or not. From the design perspective it seems I should but it also adds some overhead I suppose...
[3086 byte] By [
Hombrea] at [2007-11-27 1:58:55]
# 2
If your getter look like asprivate JButton getRun() {
return run;
}
Then it was fairly useless. But I don't see why they should be evil. Please elaborate "evil".
And please also elaborate "overhead". I also don't see any serious overhead.
Personally I should have called your "getRun" method "createButton", or "loadButton", or so. Because this is strictly looking not a getter.
# 6
> I use accessor methods when writing persistent
> classes and javabeans. The key is not to use them by
> default, only when required. IMO this does not
> violate encapsulation, it hides implementation.
Agree. Inside the bean itself you shouldn't use it's accessors either.
> The
> main benefit being that should you need to refactor
> the way a value is retrieved or set you have
> localized the changes. Holub will tell you that if
> you are using an accessor method to retrieve a value
> from an object, in order to do some computation on
> that value, you should move the computation into the
> object's class instead (hence "getter and setter
> methods are evil").
Summarized, the public accessors are evil when the code behind does not *only* return/set the encapsulated value. Solution: refactor, split and rename them to "createSomething", "lookupSomething", "buildSomething", or so.
In this case the topicstarter was talking about private getters tho.
# 9
Not evil, but it does not 'buy' you anything either. Private accessors will return private instance (or static) variables.However, you can access these directly in the class already.
There are other use cases, such as exposing a private instance variable via a protected or package-private accessor to subclasses or package classes. Here, the other classes cannot (and should not) access the private instance variable in the first place. So, you have better control over an object's state by exposing the variable in this way (same with public accessors, really).
But for a private variable, you cannot 'hide' the variable and 'force' other developers to use your method. In terms of run-time performance, I agree that this will be negligible. But in terms of increasing development time, you may end up producing less functionality overall simply to expose variables that are already exposed to the enclosing class.
- Saish
# 10
> Can't say I have ever found the need for private
> accessor methods. Writing them is all well and good
> until someone else comes along to maintain your code
> and just accesses the variable directly.
>
> -
Could be useful if you have something you don't want to expose to the outside world YET.
Make it private, and at some later date change that to public.
But I'd more likely make it protected or package private so that I can at least write a test harness for it.
