Bdtjtk

We plan to apply the command pattern in our process management project: there are

• a Command interface to implement


• a CommandProcessor, which truly execute some task

The CommandProcessor is passed to the Command instance through constructor so that the execute() method in Command will eventually trigger the true execution in CommandProcessor

So the code of CommandProcessor looks like this:

public class CommandProcessor {

    public doWork1() {

      //implementation

    }

    public doWork2() {

      //implementation

    }

    public doWork3() {

      //implementation

    }



    ...



    public doWork200() {

      //implementation

    }

}

As the code snippet indicates, the downside of command pattern in our use case is there might be hundreds of commands and thus the CommandProcessor might be difficult to maintain in the long term. So how to resolve this drawback?

This does not feel like the command pattern to me. the design you have highlighted does not hide the implementation detail from the caller. It puts all the logic for which method to call with the caller rather than it being hidden behind an interface.

The main reason for the Command pattern is the caller of the command does not need to know anything at all about what the command is, what it does, all of that is encapsulated in the command itself.

I feel your fears about having 200 command methods have merit. Firstly consider what happens when you add, remove or change the signiture of any of these work methods. Not only do you need to change the interface but also all the concrete classes that implement that interface, and all the locations where the interface is called.

Typically the command pattern has one execute interface, see this wikipedia article for a description of the command_pattern

As @robert mentioned in your comments i think you should rethink your API.

Edit

After a good conversation with @Rui I better understand the question and have the following to say.

Whilst I misunderstood the original question I'm still prepared to stand by the statement that a redesign is needed. Whilst the command pattern is being followed I dont think the spirit of the pattern is. The object passed to the commands (the commandProcessor) is the receiver of the commands actions, but this does not look like a proper object. Obviously I lack context but for me any object that ends in -er raises big flags as not really being an object, but more a collection of methods that act on someone elses data.

Here is a good little write up with some links. I often find that classes like managers, processors or helpers go hand in hand with an Anemic Domain Model. Maybe you are on the beginnings of the right track and i would challange you to look at that commandProcessor and see if its not actually a number of descrete objects that can encapsulate their own data and methods.