Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: use case for extending enum, but this is not possible in java Date: Sun, 15 Jun 2014 12:20:08 +0200 Lines: 199 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net AYaBn8Rk3tBKUA/iMghJBQZKKb8wpgkHlLeg06XdwtTOs5JUI= Cancel-Lock: sha1:LYpF5YRrulDG+Fi0WAxjOsoENyU= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:28744 On 15.06.2014 01:24, Laura Schmidt wrote: > Hi, > > I have found a need to extend enum, but this is not possible in java. > Take a look at the situation: > > In an application, there is an enum ListCommand that enumerates the > commands a user may execute on list entries: > > public enum ListCommand > { > OPEN, > EDIT, > DELETE; > } > > There is an interface that uses this enum: > > public interface ListCommandProcessor > { > void onListCommand (ListCommand cmd); > } > > And there is a generic Listing class that is used to show customized > lists in the GUI and which uses the above interface: > > public class Listing > { > ... > ListCommandProcessor processor; > ... > } > > So far, so good. > > Now I am making a cut: The generic class Listing should be moved into > a generic java library, so that it can be used by different > applications. So I also need to move the interface ListCommandProcesor > into this library, and this would implicate that I also move the enum > ListCommand into the library. But the enum ListCommand ist application > specific. If I move it to the library, it must be extendable somehow. If > there were no limitations in the java language, I would separate the > concerns of library and application like this: > > --- library: > > public enum ListCommand > { > // empty at library level > } > > public interface ListCommandProcessor > { > void onListCommand (ListCommand cmd); > } > > --- application: > > public enum AppListCommand extends ListCommand > { > OPEN, > CLOSE, > SOMETHINGSPECIAL; > } > > public class MyApp extends ListCommandProcessor > { > ... > Listing listing = new Listing (); > listing.setProcessor (this); > > public void onListCommand (ListCommand cmd) > { > AppListCommand c = (AppListCommand) cmd; > > switch (c) > { > ... > } > } > } > > This would be my solution, but it is not possible in java to extend > enums. But I need to make a cut somewhere in order to move Listing > into the generic library. The only solution I can imagine is to change > > onListCommand (ListCommand cmd); > > into > > onListCommand (int cmd); > > But then I would loose the beautiful type binding and I will soon find > myself defining list commands like it was done in the 90's in C: > > public static final int CMD_OPEN = 1; > public static final int CMD_EDIT = 2; > public static final int CMD_DELETE = 3; > public static final int CMD_SOMETHINGSPECIAL = 55; > > I know that this would be a way out, but I want to make sure that there > is no better solution. > > How would you do this? To me this is pretty clear: ListCommandProcessor is an interface and needs an application specific implementation anyway to interpret the argument to onListCommand(). As you do not seem to define specific methods in ListCommand any implementation of onListCommand() is basically totally free to do what it needs to do with the argument and you do not have to constrain the argument type in any way. So you make it generic. So we have Library part: public class Listing { ... private ListCommandProcessor processor; ... } public interface ListCommandProcessor { void onListCommand(C cmd); } Specific implementation: public class MyList { } public enum ListCommand { OPEN,EDIT,DELETE } public class MyApp implements ListCommandProcessor { ... Listing listing = new Listing (); listing.setProcessor(this); public void onListCommand(ListCommand cmd) { switch (cmd) { ... } } } An alternative approach might be to remove ListCommandProcessor altogether and use a more OO approach by implementing functionality inside the ListCommand (what is an enum now but could be something else). Library part: public interface ListCommand { void execute(T list); } public class Listing { ... public void someMethod() { final T list = ... final ListCommand cmd = ... cmd.execute(list); } ... } Specific implementation: public class MyList { } // this could be anything, not just an enum public enum MyListCommand implements ListCommandProcessor { OPEN { @Override public void onListCommand(MyList cmd) { // whatever } }, EDIT { @Override public void onListCommand(MyList cmd) { // whatever } } ... } Kind regards robert