Ways to decouple implementation from an enum?

For me it's weird to add methods to enums; and with your Foo, Bar example its not clear what you achieve in this case by doing so as each enum value is the same implementation.

Furthermore, java won't allow you to pass in a dependency via the constructor at runtime so you can't do standard DI stuff to decouple the logic.

Your solution looks fine, but doesnt really decouple the logic as you have a static link in the constructor.

Why not use a standard class with an enum type field?

public enum IconTypes {
  FOO,
  BAR,
  BAZ;
  }
public static final Icon[] TEXTURELAYERSv1 = { new Icon(FOO), new Icon(BAR) };
public static final Icon[] TEXTURELAYERSv2 = { new Iconv2(FOO), new Iconv2(BAR) };

Now you have full control over the implementations and direct access to the Icon methods.

However, if you have a performance critical loop I think you would have to assume that any call on a class might be delegated. You should allow classes to be replaced without having this kind of implicit assumption about their internals.

So in such a loop it would be prudent to get the raw information the loop is using rather than call the class methods each loop ie.

void PerformantLoop()
{
   var bitmap[] textures;
   foreach(Icon in TEXTURELAYERSv1)
   {
      textures.Add(Icon.getTexture()) //potentially delegated/loads from disk/sends an email to get artist to draw by hand etc
   }
   while(true)
   {
      //render from textures not TEXTURELAYERSv1 
   }
}

After hours of searching, the delegates pattern is the only way to extract implementations from an enum in Java.

That said, the enum only held constants.

As it turns out, an abstract class is a better fit here.

Here is how an abstract class can give direct access to the real instance of the implementation from the constants without exposing the actual implementation:

public abstract class Icons implements IconContainer {
  // Constants directly reference the real internal instances (no wrapper)
  public static final IconContainer
    FOO = create("FOO"),
    BAR = create("BAR"),
    BAZ = create("BAZ");
  // Provide implementation from internal package
  private static create(String name) {
    return InternalIconContainerImpl.create(name);
  }
}

Now FOO, BAR, BAZ all directly reference an implementation without a delegated indirection.

the private create helper reduces the verbosity of the constants initialization while centralizing the instantiation code.

The Java's programming language enum it is singleton design pattern implementation. This...

public enum Icons implements IconContainer {
    FOO, BAR, BAZ;
}

... it is same with this ...

public class Icons {
    public static final Icons FOO = new Icons() { . . . };
    public static final Icons BAR = new Icons() { . . . };
    public static final Icons BAZ = new Icons() { . . . };
}

... where FOO, BAR, BAZ are instances of anonymous inner classes extending Icons class. By the encapsulation of each concern in its own class the separation of concerns it's implemented, to take one step further the separation of concern each anonymous class extending Icons class should be replaced with classes each defined in its own file that would separation of concerns per file. The concern to move each anonymous class each in its own file is readability.

The enum can be employed exactly as with the old API, each enum value is "implementing" the IconContainer by delegation.

... and ...

// Getter of the delegate to access the real implementation
IconContainer getDelegate() {
  return this.delegate;
}

... are contradictory, since the later is replacing the use of interface with the use of implementation.

Are there other means to decouple implementations from an enum without using delegate as I did?

In place implementation of the interface...

public enum Icons implements IconContainer {
    FOO {
        // FOO specific implementation
        @Override
        public Icon getIcon() { . . . }
        @Override
        public Icon getOverlay() { . . . }
    }
    , BAR {
        // BAR specific implementation
        @Override
        public Icon getIcon() { . . . }
        @Override
        public Icon getOverlay() { . . . }
    }
    , BAZ {
        // BAZ specific implementation
        @Override
        public Icon getIcon() { . . . }
        @Override
        public Icon getOverlay() { . . . }
    };
    private Icons() { . . . }
    @Override
    public Icon getIcon() { }
    @Override
    public Icon getOverlay() { }
}

... although for complex use cases the readability decreases and probably that is what sourced the approach of having each implementation in it's own class and in it's own file.