When implementing an engine independent command (one that performs an abstract operation on all rows), you have to copy code that's already in EngineDependentCommand::doPost. Validating the CSRF token, getting the project, creating a process, and handling the response are necessary when writing a command that performs abstract operations on all rows, too.

It also seems counter intuitive to implement engine independent commands by extending Command directly because Command has two methods for working with engine configuration:,getEngineConfig() and getEngine().

Proposed solution

From discussion in #1855 and at the suggestion of @tfmorris, I'm wondering what folks think of refactoring the Command class hierarchy to facilitate the development of new commands and refactor existing engine independent commands for maintainability.

In my mind, I think it'd be nice to have three abstract classes:

• Command
  • EngineDependentCommand
  • EngineIndependentCommand

Alternatives considered

• Continue extending Command: It's not hugely annoying to extend Command and override doPost when writing an engine independent command because those useful methods are hoisted in the super class. But it still feels redundant.

• Extend EngineDependentOperation and ignore engineConfig when overriding EngineDependentCommand::createOperation: This is actually what ReorderColumnsCommand does.

Additional context

As a newbie to OpenRefine's codebase, my initial instinct was just to extend the EngineDependentCommand when tinkering around with a command for adding rows to a project.

Among the core commands, these engine independent commands (in particular) basically copy EngineDependentCommand::doPost or extend EngineDependentCommand and ignore engine configuration:

• RenameColumnCommand
• RemoveColumnCommand
• ReorderColumnsCommand
• JoinMultiValueCellsCommand
• TransposeColumnsIntoRowsCommand