3

I have been going back and forth in a discussion about polymorphic enums to call different DAO methods depending on enum entry, and I haven't been able to get a common agreement on this subject.

Lets say you have an enum that controls your response style, (short and detailed), and then you override a method to get that info at enum level, something like what I wrote below

public enum ResponseStyle {
 short {
    @Override
    public List<Response> get(){
      calls to some database template method
    },   

 detailed {
    @Override
    public List<Response> get(){
      calls to some database template method
    }
  }
}

And that code is called from DAO with responseStyle.get, is that bad design? My intent was to future proof possible new response style implementations, and go towards heuristic determination instead of chaining If or Switch statements, but I wonder if this breaks the DAO pattern.

  • OK, so I did a bit of reading about this, and I'm decidedly not a fan. You can do better (and simpler, and easier to understand, and cleaner) by simply using ordinary higher-order functions in a dictionary/hashtable, or factory methods or constructor overloads. See also here. – Robert Harvey May 21 '19 at 14:47
  • @RobertHarvey when u saying higher-order functions, can u give an example? U have different templates for each enum entry, same dao, how to handle it in a clean manner ? – Danilo Silva May 21 '19 at 18:51
  • I think you are talking about returning a method reference to a DAO method from this get in Enum, but not sure if thats it. – Danilo Silva May 21 '19 at 18:56
  • This example uses Javascript, but it illustrates the basic idea: hackernoon.com/… – Robert Harvey May 21 '19 at 19:01
0

You should ask yourself if the behavior of the program changes between short and detailed ResponseStyle or if purely the data changes. If it is the latter, then enum should, if anything, should use its label as a prefix in a lookup in a properties file with all the data required. The behavior therefore remains the same and consistent.

If the behavior changes, then you're potentially looking at what would probably be a very complex enum declaration with multiple behaviors, each one inconsistent with another. In that case you should probably prefer a factory method or even an abstract factory pattern, which when given a ResponseStyle enum, will appropriately give a list of Response instances.

In either case, I feel that your approach is not ideal. Enums can be the pivot which connects usage and implementation, but avoid cluttering whenever possible.

  • As of now, the enum only controls whether a projection list is passed to mongo or not, and different methods are called. The data returned looks different, but the problem is that different methods are supporting each style. Also I am not a fan of having a huge chain of if statements to evaluate everything. From my point of view, the change in behavior is just a different method call, and going to a AF pattern seems like over-engineering, plus YAGNI, since nothing else changes between the two styles. – Danilo Silva May 21 '19 at 10:32
  • @DaniloSilva You can still accomplilsh this using enums, just don't make it the focal point. If anything, associate the enum with a class and then call that class. At least it keeps the enum simple. – Neil May 21 '19 at 10:48
  • I reverted back to if evaluation in DAO level to call a different method. The enum will never grow anyway. – Danilo Silva May 21 '19 at 12:39

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.