Singletons, Enums and anonymous inner classes

Question

As you may know, some people are declaring singletons with an Enum of 1 instance, because the JVM guarantees that there will always be a single instance with no concurrency problems to handle...

Thus what about an Enum with multiple instances? Can we say something like an Enum is a kind of ordered set of singletons sharing a common interface? Why?

public enum EnumPriceType {

    WITH_TAXES {
        @Override
        public float getPrice(float input) {
            return input*1.20f;
        }
        public String getFormattedPrice(float input) {
            return input*1.20f + " €";
        }
        },

    WITHOUT_TAXES {
        @Override
        public float getPrice(float input) {
            return input;
        }
    },
    ;

    public abstract float getPrice(float input);

    public static void main(String[] args) {
        WITH_TAXES.getFormattedPrice(33f);
    }

}

In this code why this doesn't work: WITH_TAXES.getFormattedPrice(33f); What is the interest of declaring a public method if it can't be called without passing through the common interface? I guess this is why i don't see any syntax to be able to declare an interface just for one of the instances of an Enum.

---

Edit:

It seems that enum instances are a special kind of anonymous classes. Thus i understand why you can't call that method.

My question is kinda related to: why can't an anonymous class implement an interface (in addition to the interface it may already implement!)

I totally understand why we CANT do that:

Vehicle veh = new Vehicle() {
    public String getName() {
        return "toto";
    }
};
veh.getName();

(getName here is not an override)

Why i don't understand is why we can't do that with anonymous classes:

Runnable veh = new Vehicle() implements Runnable {
    @Override
    public void run() {
        System.out.println("i run!");
    }
};
veh.run();

Or something that would result in the same thing. Think about it: if you do not use anonymous classes you can absolutely extend the Vehicle class and then make that subclass implement any other interfaces you want...

I'm pretty sure that if it was possible we would be able to call WITH_TAXES.getFormattedPrice(33f) in a typesafe way, since WITH_TAXES would not be a real EnumPriceType but it would but a subclass of EnumPriceType, with its own interface, and by calling WITH_TAXES.getFormattedPrice(33f) with a hardcoded WITH_TAXES, you know at compile that which EnumPriceType child you are calling.

So my question is: are there any reasons why this is not possible? Or it just haven't be done yet?

Answer 1

Your enum is equivalent to the following normal class (in fact, that's pretty much what the compiler turns it into):

public abstract class EnumPriceType {

    public static final EnumPriceType WITH_TAXES = new EnumPriceType() {
        //getPrice() {...}
        //getFormattedPrice() {...}
    };

    public static final EnumPriceType WITHOUT_TAXES = new EnumPriceType() {
        //getPrice() {...}
    };

    public abstract float getPrice(float input);

    public static void main(String[] args) {
        WITH_TAXES.getFormattedPrice(33f);
    }
}

The getFormattedPrice() method is unavailable on the abstract type, and therefore can't be called from the main method. Consider what would happen if the main method is rewritten to use a local variable:

public static void main(String[] args) {
    EnumPriceType foo = EnumPriceType.WITH_TAXES;
    foo.getFormattedPrice(33f);
}

This doesn't compile because getFormattedPrice() is not available on the base class. Since the WITH_TAXES instance is an anonymous subclass of EnumPriceType, there's no way you can define the local variable to a type where the getFormattedPrice() method is visible.

As a meta observation, this is a key difference between strongly typed languages such as Java and "duck typed" languages such as Ruby. Ruby will happily invoke the getFormattedPrice() method if happens to be there, regardless of what type of object is held in the foo variable.

As another meta observation, it doesn't make much sense for different constants of the same enum to have different sets methods. If you can't put everything you need as abstract (or concrete) methods on the base enum type, you're probably using the wrong tool to solve the problem.

Answer 2

Add

       public String getFormattedPrice(float input) {
        return input + " €";
    }

outside the overrides as the default implementation. (Next to the declaration of getPrice.) And you are good to go.

You can also have enums implement interfaces, to define what everybody needs to implement.