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

In article <lniljr$8h9$1@news.m-online.net>, Laura Schmidt
(ls@mailinator.com) says...


[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.


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 ---