Should I avoid using getX() and setX() as names for methods that aren't traditional getters or setters? (Let's define traditional as it only gets/sets the field and has no other effects.) I guess the question is does a method being named as such imply that it's a field of the object? Also, is it bad practice to do other things in them?class Foo {    private Object bar;    private Object bazz;    // traditional    public Object getBar() {        return bar;    }    // bad practice?    public Object getBazz() {        doSomeOtherThing();        return bazz;    }    // not a field    public Object getJazz() {        return makeSomeJazz();    }    // ...}If getX() isn't appropriate if it's not a field, what is? (Probably too broad, I realize.) Obviously something like makeJazz() is probably better than getJazz() if getJazz() is considered bad here.I guess another question is does it really matter? I like the idea of self documenting code, but maybe I'm just worrying too much about something minor.
Should method names getX and setX only be used for fields and have no other effects?
java;object oriented;naming
Let's say you're writing a GUI control, and you want to be able to resize it.  Intuitively, you should have a setHeight method and a setWidth method for the dimensions.  These should set a value on the control, but if they don't also cause the control to recalculate and redraw itself, you're violating the heck out of POLS, because your user is going to expect changing the size of the control to visibly change the size of the control.  (Not to mention leaving the control in an inconsistent state, because the backing field value doesn't match what's shown on screen.)Instead of set a value and have no other effects, your rule of thumb should be do what is necessary to bring the object into a fully consistent state, but nothing more.  Sometimes this will only require setting a value.  Other times, it'll take a lot more work.