Is it okay to use non-static getters and setters for static variables?

Question

Will the following design prove hard to scale in the long run:

class A {
    private static volatile boolean someFlag;

    public void setSomeFlag(boolean newFlag) {
        someFlag = newFlag;
    }

    public boolean getSomeFlag() {
        return someFlag;
    }
}

I want to do this in a project because, in my case, A implements an interface and the interface has implementations other than A, all of them being singletons. All implementations will have someFlag and perform related operations (get and set). But the state of someFlag is implementation specific, so I can't just make someFlag a static member of interface and define static getter and setter as part of the interface itself. I want to know if it is acceptable to go with the design of the class above?

Possible duplicate of Make methods that do not depend on instance fields, static? — gnat, Sep 09 '19 at 09:34
Also, what you think is a singleton today might not be one two years from now. I wouldn’t make it static just because today there is only one instance. — gnasher729, Sep 09 '19 at 10:48
@gnasher729 The flag was not static because the class was a singleton. I was confused. When I wrote it first, I didn't think of making the implementations singletons and to prevent multiple instances of the same implementation to have its own flag, I made the flag static. The project I'm doing requires data to be captured from multiple sites. The procedure to grab data from them are different. I decided to define an "engine" interface, implementations of which are the procedure to extract data from each website. The flag notifies error. If it's set, the corresponding engine has failed. — Devashish, Sep 09 '19 at 15:07

score 4 · Accepted Answer · edited Sep 09 '19 at 12:49

4

If your objects are singletons there is no need to make the instance variable static. You can simply use a normal property with getter / setter.

As gnasher729 already said, having a non-static setter for a static instance variable is fishy.

edited Sep 09 '19 at 12:49

marstato

4,578

answered Sep 09 '19 at 10:08

Mathias Mamsch

293

Now I'm thinking why I didn't think of that before. – Devashish Sep 09 '19 at 10:12
I agree that this is fishy. But If, for some reason, the var has to stay static for now, that doesn't mean you should always make it's getter static. Static is sometimes not a good thing to spread around. You can hide it and preserve the ability to refactor the static var later. – candied_orange Sep 09 '19 at 19:15

score 2 · Answer 2 · answered Sep 09 '19 at 09:45

2

The non-static getter makes some sense. I can ask each instance about some property, and by coincidence they all return the same value.

The non- static setter is wrong. Setting a property of an instance shouldn’t change properties of other instances.

You could make it a getter only, and have a class method “setPropertyForAllInstances”. Or leave it static.

answered Sep 09 '19 at 09:45

gnasher729

44,814
4
64
126

I forgot to mention that the implementations are supposed to be singletons. – Devashish Sep 09 '19 at 09:49
@Devashish Rather than have all this static, why not just have an ordinary class that so happens to only get newed once? – Caleth Sep 09 '19 at 10:07

Is it okay to use non-static getters and setters for static variables?

2 Answers2