Java – Static Set and Non-Static Get Methods

javaobject-oriented-design

I've the following Interface.

public interface ValueInterface
{
  long  getValue();
}

And the class:

public class ValueCreator implements ValueInterface
{
  private static long value  = 0;

  public void setValue(long valueInDollar)
  {
    value= valueInDollar;
  }

  @Override
  public long getValue()
  {
    return value;
  }
}

The static code analyzer findbugs warned me not to set a static field in a non-static method. If I make the set method static, I can't make the getter static as it is an interface overridden method.

So, is it okay to have a static setter and non-static getter or what could be a better approach?

Best Answer

No, it is not a good idea to have a non-static getter for a static field.

The problem is that you can have multiple instances of ValieCreator, but they will all share the same static value field, so all instances will always return the same value and if you change the value through one instance, the modification is visible in all.
This is compounded by the fact that the getter is declared in the ValueInterface interface. Suppose you have this code:

void SillyMethod(ValueInterface i, ValueCreator c)
{
    if (i != c)
    {  // different objects
        long val = i.getValue();
        c.setValue(val+1);
        if (val != i.getValue())
        {
            // Huh? Setter on c changed the value on a different object?
        }
    }
}

It is better to make the value field non-static. If you must ensure there can only ever be one ValueCreator, then you can use the Singleton pattern for that (but first ensure that there is no scenario imaginable where there might be two or more ValueCreator objects).

Related Solutions

Java – How to decouple simple factory and default implementation

No, an IOC container is not necessary to decouple the API and non-API classes. Because they're not really coupled.

FileResources is coupled to Path and to FileResource, but not to DefaultFileResource. That is, if you change Path or FileResource, there is a risk of breaking FileResources. Albeit not a large one. Those are pretty thin layers; that's an acceptable coupling.

However, if you change DefaultFileResource, as long as it still conforms to FileResource, you cannot break FileResources.

You wouldn't even break any tests for FileResorces. They test only that a DefaultFileResource is returned, under the default conditions, and that's fine.

Even more importantly, your calling code is not coupled to any particular implementation of FileResource either. That's good. In fact it's the whole point of a Factory Method. (And this is a Factory Method. There is no Factory Class distinction, in the context you've used it; it doesn't matter whether the Factory Method exists in another class.)

However, your calling code IS coupled to FileResources. Most notably, if you change the implementation of FileResources, there is every chance you would break any unit tests that are testing your calling code, because the get method cannot be stubbed out.

That is a much bigger concern than any knowledge FileResources has about DefaultFileResource.

The only reason you would use an IOC container for the factory is if you want to build up DefaultFileResource with its dependencies. I would avoid that unless you need it and, if you should need it, I would take a look around at the Service Locator pattern and why is should be avoided, before I decided on the use of that IOC container.

Java 8 Interfaces – Why Were Default and Static Methods Added to Interfaces in Java 8?

A good motivating example for default methods is in the Java standard library, where you now have

list.sort(ordering);

instead of

Collections.sort(list, ordering);

I don't think they could have done that otherwise without more than one identical implementation of List.sort.

Best Answer

Related Solutions

Java – How to decouple simple factory and default implementation

Java 8 Interfaces – Why Were Default and Static Methods Added to Interfaces in Java 8?

Related Topic