项目耦合度高，能否为多参数多返回值操作应用命令模式？

Great question! The classic Command pattern's void-only execute() method might feel restrictive for your use case, but you absolutely can adapt it to fit operations with varying parameters and return types—this is actually a common tweak to the pattern when dealing with real-world, diverse operations like file/registry/process handling or system requirement checks.

Here’s how to approach it:

1. Use a Generic Command Interface #

Instead of a one-size-fits-all void execute(), define a generic interface that lets you specify both input parameter types and return types. This keeps the pattern flexible while maintaining its core decoupling benefit.

Example interface (concept translates to most OOP languages):

public interface Command<TInput, TOutput> {
    TOutput execute(TInput input);
}

• For a file copy operation, you might implement Command<FileCopyParams, Boolean> (returns success status)
• For a registry read operation, Command<RegistryQueryParams, String> (returns the registry value)
• For a system requirement check, Command<SystemCheckSpecs, SystemCheckResult> (returns a detailed pass/fail object)

2. Wrap Multiple Parameters in Parameter Objects #

If an operation needs more than one input (e.g., source path, destination path, and overwrite flag for file copy), don’t clutter the execute() method with multiple arguments. Instead, create a dedicated parameter class to hold all relevant data.

Example parameter class:

public class FileCopyParams {
    private String sourcePath;
    private String destinationPath;
    private boolean overwriteExisting;

    // Constructor, getters, setters
}

This keeps your Command interface clean and adheres to the Single Responsibility Principle.

3. Handle Void Returns (When Needed) #

For operations that truly don’t need to return anything (e.g., a process shutdown command), you can use the Void type as the return parameter:

public class ShutdownProcessCommand implements Command<ProcessIdParam, Void> {
    @Override
    public Void execute(ProcessIdParam input) {
        // Shutdown the process logic
        return null; // Required for Void return type
    }
}

Alternatively, you could create a separate VoidCommand interface if you prefer, but the generic approach works seamlessly.

4. Build a Flexible Invoker #

Your original tightly coupled class can be refactored into an Invoker—a class that handles executing commands without knowing their specific implementation details. This is where you’ll decouple all your operations.

Example invoker:

public class OperationExecutor {
    public <TInput, TOutput> TOutput runCommand(Command<TInput, TOutput> command, TInput input) {
        return command.execute(input);
    }
}

Using it looks like this:

// Set up command and parameters
FileCopyParams copyParams = new FileCopyParams("/source/file.txt", "/dest/file.txt", true);
Command<FileCopyParams, Boolean> copyCommand = new FileCopyCommand();

// Execute via invoker
OperationExecutor executor = new OperationExecutor();
Boolean copySuccess = executor.runCommand(copyCommand, copyParams);

// Repeat for other operations
SystemCheckSpecs checkSpecs = new SystemCheckSpecs(8192, "Windows 10");
Command<SystemCheckSpecs, SystemCheckResult> checkCommand = new SystemRequirementCheckCommand();
SystemCheckResult checkResult = executor.runCommand(checkCommand, checkSpecs);

5. Bonus: Add Error Handling (Optional) #

You can extend the Command interface to include exception handling if needed, or wrap returns in a Result<T> object that holds both the success data and error messages. This makes error handling consistent across all your operations.

Why This Works #

By adapting the Command pattern with generics and parameter objects, you:

• Eliminate tight coupling between your original monolithic class and individual operations
• Each Command class now has a single responsibility (e.g., only file operations, only registry reads)
• Keep your codebase modular and easy to extend (add new operations by creating new Command implementations)
• Maintain the core benefit of the Command pattern: encapsulating requests as objects, which lets you queue, log, or undo operations later if needed

内容的提问来源于stack exchange，提问作者Avikal Rai