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 9 '19 at 9: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 9 '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 9 '19 at 15:07

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.

  • Now I'm thinking why I didn't think of that before. – Devashish Sep 9 '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 9 '19 at 19:15

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.

  • I forgot to mention that the implementations are supposed to be singletons. – Devashish Sep 9 '19 at 9: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 9 '19 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.