Command Pattern clarification

Question

I cannot see any of the command pattern classes e.g. invoker, receiver manifesting in the accepted answer of the following link Long list of if statements in Java. I have gone with the accepted answer to solve my 30+ if/else statements.

I have one repository that I am trying to pass DTOs to save to the database. I want the repository to invoke the correct save method for the DTO so I am checking the instance type at runtime.

Here is the implementation in Repository

private Map<Class<?>, Command> commandMap;
public void setCommandMap(Map<Class<?>, Command> commandMap) {
    this.commandMap = commandMap;
}

and a method that will populate the commandMap

    commandMap.put(Address.class, new CommandAddress());
    commandMap.put(Animal.class, new CommandAnimal());
    commandMap.put(Client.class, new CommandClient());  

and finally the method that saves

public void getValue(){
    commandMap.get(these.get(0).getClass()).save();
}

The service class that uses the Repo registers the commandMap.

Does the accepted answer represent a sort of (approximate) implementation of the Command pattern?

Answer 1

It seems like an enum that implements an exec interface will eliminate your if/else problem or turn it into a switch.

It does not look like you need a command patterm.

Gof says:

Use the Command pattern when you want to

    parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.

    specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there.

    support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively.

    support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation.

    structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.

Which of the above do you want to do?