0

This is posing a heated debate and I would like to know if there are any problems with this approach.

I have a class which contains nothing but static strings:

public class EventConstants {
    public static ID = "1";
    public static DOMAIN = "local";
    public static final DEVICE = "PC";
    public static final SOURCE = "local";
}

Now the reason ID and DOMAIN are not final is because I have chosen to override them given Spring ConfigurationProperties. So...

public CustomEventConstanstants extends EventConstants {

    @Autowired
    private PropertyMapper mapper;

    @PostConstruct
    public void init() {
        ID = (mapper.ID != null) ? mapper.ID : EventConstants.ID
        DOMAIN = (mapper.DOMAIN != null) ? mapper.DOMAIN : EventConstants.DOMAIN
    }
}

The idea behind this class is the user can simply call one class and use the appropriate constant as configured by a Spring property or not. Example:

object.methodA(CustomEventConstants.ID)  // This will return the configured ID or what's in EventConstants
object.methodB(CustomEventConstants.DEVICE)

The argument I'm having is other's believe it is not appropriate for testing since it cannot be appropriately Mocked out.

jiveturkey
  • 2,484
  • 1
  • 23
  • 41
  • Just use a default environment and then different environment properties which override the default one – Lino Jun 27 '18 at 17:38
  • You don't need a `Properties` instance here, just refer to it as `Properties.ID`, `Properties.DOMAIN` etc. You would get any "overridden" values anyway, since static members are not polymorphic. – Andy Turner Jun 27 '18 at 17:39
  • @AndyTurner My mistake - huge error in class name. I edited the code, I was being terse and forgot about the `Properties` class. I updated it to our own `PropertyMapper` which is our Spring configuration. – jiveturkey Jun 27 '18 at 17:53
  • @Lino Can you explain your comment a little more. Won't I still need to make this a Bean? – jiveturkey Jun 27 '18 at 17:54
  • What can't be mocked out, and why not? – Dave Newton Jun 27 '18 at 19:17
  • @DaveNewton Well, this class (or at least EventConstants), was being used throughout a number of tests in a couple of other projects. I was tasked with extending it with this flexibility yet not really impacting the resting of the existing code base. When testing the other projects, the will now have to enable a SpringContext (even if they didn't need one) and go through the process of Mocking out this class. – jiveturkey Jun 27 '18 at 19:31
  • You could have an intermediary class taking a mapper in its ctor: in the Spring version you can wire a mapper via annotations but use that mapper to instantiate the intermediary class. In non-Spring codebases you use only the intermediary class and construct it however you want. – Dave Newton Jun 27 '18 at 19:42
  • @DaveNewton Not a bad idea. I think they are just annoyed they want to do any more work :) – jiveturkey Jun 27 '18 at 19:59

0 Answers0