Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28756

Re: use case for extending enum, but this is not possible in java

Show all headers | View raw

In article <lniljr$8h9$1@news.m-online.net>, Laura Schmidt 
(ls@mailinator.com) says...
> 
> 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<T>
> {
>   ...
>   ListCommandProcessor processor;
>   ...
> }

[SNIP]

So basically what you're trying here is using an Enum as an event and of 
course that must fail in another application that needs more events than 
these. An Enumeration is just that: An enumeration, a fixed set of 
things. Since you want something extensible an Enumeration is not the 
weapon of choice.

> How would you do this?

According to your sample, you've picked one name to do something but 
you're doing something else.
Your naming suggest you want to process commands, but your 
implementation suggests you're processing events.
So why not stick with your naming and try to process commands instead?
That would inevitably point you to the Command Pattern for a start. 
that could look like a biut like this:

//you want something extensible, so use a class, an abstract class or an 
//interface:

package commands;
public interface ListCommand{ 
 void execute();
}

//now extend it:

//let's also hide the implementations using package visibility, 
//more on that later

package commands;
class Remove implements ListCommand{
  private final int index;
  Remove(Listing listing, int index){
   this.listing=listing; //or an ID,whatever is appropriate
   this.index=index;
  }

 public void execute(){
  //maybe do something specific here, like logging
  listing.remove(index);
 }

}

//let's create an interface for command processing:

public interface ListCommandProcessor {
 public void process(ListCommand command);
}

//and have a basic implementation for the basic case. That doesn't look 
//like rocket science (and pretty unnecessary), but read on:

package commands;
public class BasicListCommandProcessor implements ListCommandProcessor {
 public void process(ListCommand command){
   command.execute();
 }
}

// Now expose your commands via a Facade class, so you users don't need 
// to remember the implementations, so they have a single go-to-class. 
// And they don't see all the dirty implementation details:

package commands;
public class BasicListCommands{
 
 public ListCommand remove(Listing listing, int index){
  return new Remove(Listing, index);
 }

 public ListCommand edit(Listing listing, int index){
  return new Edit(Listing, index);
 }

 ///...

}

That's your framework, basically. Note that I'm not using static methods 
or singletons or a final class, we want to be open for extension here.
Which we will do now.

You could now extend your suite of commands by creating own command 
implementations and extending the suite:

//only visible in project A, that uses the framework above.

public class MyProjectListCommands extends BasicListCommands{

 public ListCommand magicOperation(final List list){
  return new MagicOperation(list);
 }
}

You could override the default behavior and add someting:

//only visible in project B, that uses the same framework above:

public class MyOtherProjectListCommands extends BasicListCommands{

 @Override
 public ListCommand edit(Listing listing, int index){
  return new SpecialEdit(Listing, index);
 }

 public ListCommand fascinatingOperation(final List list){
  return new FascinatingOperation(list);
 }
}


So for any bogus usage example, let's process some commands:
Imagine we want to do some special processing, logged and/or parallel:

//create some decorator to log every command
public class LoggingListCommandProcessor implements ListCommandProcesso{
 private static final Logger LOGGER 
   = Logger.getLogger(LoggingListCommandProcessor.class);

 private final ListProcessor delegate;

 public LoggingListprocessor(ListProcessor delegate){
  this.delegate = delegate;
 }

 public void process(ListCommand command){
  LOGGER.trace(command);
  delegate.process(command);
 }

}

//Imagine another decorator for doing parallel processing here

Now let's see how this could be used in some project with an extended 
command suite:

class Client{
 private static final MyProjectListCommands COMMANDS 
   = new MyProjectListCommands();

 private final ListCommandProcessor processor 
  = new LoggingListCommandProcessor(
     new ParallelListCommandProcessor(
      new BasicListCommandProcessor()
     )
    );

 void doEdit(){ 
  processor.process(COMMANDS.edit(someList, someIndex));
 }

}


So you see: you've got a whole lot of possibilities if you use good old 
classes and interfaces instead of enums here.

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

use case for extending enum, but this is not possible in java Laura Schmidt <ls@mailinator.com> - 2014-06-15 01:24 +0200
  Re: use case for extending enum, but this is not possible in java Steven Simpson <ss@domain.invalid> - 2014-06-15 01:04 +0100
  Re: use case for extending enum, but this is not possible in java Marcel Müller <news.5.maazl@spamgourmet.org> - 2014-06-15 02:53 +0200
  Re: use case for extending enum, but this is not possible in java markspace <markspace@nospam.nospam> - 2014-06-14 18:58 -0700
  Re: use case for extending enum, but this is not possible in java Robert Klemme <shortcutter@googlemail.com> - 2014-06-15 12:20 +0200
  Re: use case for extending enum, but this is not possible in java Robert Klemme <shortcutter@googlemail.com> - 2014-06-15 12:21 +0200
  Re: use case for extending enum, but this is not possible in java "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-06-15 11:58 +0100
  Re: use case for extending enum, but this is not possible in java Wanja Gayk <brixomatic@yahoo.com> - 2014-06-16 01:08 +0200
  Re: use case for extending enum, but this is not possible in java Roedy Green <see_website@mindprod.com.invalid> - 2014-06-15 22:20 -0700

csiph-web