如何重构含过多if语句的MailConfig类以减少条件判断？

Great question! This is a classic scenario where we can replace messy conditional logic with a lookup-based strategy using a Map to associate attribute names with their corresponding setter actions on the MailConfigBuilder. This approach makes the code far more scalable—when you add new attributes later, you just add a new entry to the map instead of writing another if block.

Step 1: Create a Static Mapping of Attributes to Setters #

First, we'll define a static Map that maps lowercase attribute names (to handle case insensitivity) to a function that applies the attribute value to the builder. We can use BiConsumer<MailConfigBuilder, String> to represent each setter action:

import lombok.Builder;
import lombok.Data;
import java.util.List;
import java.util.Map;
import java.util.Objects;
import java.util.function.BiConsumer;

@Data
@Builder
public class MailConfig {
    private final String subject;
    private final String mailserver;
    private final String message;
    // Example of a future attribute with special handling
    private final Integer port;

    // Static map: attribute name -> builder setter action
    private static final Map<String, BiConsumer<MailConfigBuilder, String>> ATTRIBUTE_SETTERS = Map.of(
        "subject", MailConfigBuilder::subject,
        "mailserver", MailConfigBuilder::mailserver,
        "message", MailConfigBuilder::message,
        // Example: special handling for a numeric port attribute
        "port", (builder, value) -> {
            try {
                int portNumber = Integer.parseInt(value);
                builder.port(portNumber);
            } catch (NumberFormatException e) {
                throw new IllegalArgumentException("Invalid port number: " + value, e);
            }
        }
    );

    public static MailConfig fromAttributes(List<Attribute> listofAttributes) {
        Objects.requireNonNull(listofAttributes, "list of attributes must not be null");
        MailConfigBuilder config = MailConfig.builder();
        listofAttributes.forEach(att -> mapToConfig(config, att));
        return config.build();
    }

    private static void mapToConfig(MailConfigBuilder config, Attribute att) {
        String normalizedName = att.getAttribName().toLowerCase();
        // Get the setter action, or a default handler for unknown attributes
        BiConsumer<MailConfigBuilder, String> setter = ATTRIBUTE_SETTERS.getOrDefault(
            normalizedName,
            (builder, value) -> {
                // Optional: log a warning or throw an error for unknown attributes
                System.err.println("Warning: Unknown attribute '" + normalizedName + "'");
            }
        );
        setter.accept(config, att.getAttribValue());
    }
}

Key Benefits of This Approach #

• No more repetitive if statements: All attribute handling is centralized in the map, making the code cleaner and easier to read.
• Scalable for future attributes: Adding a new property (like mailServer or ccRecipients) only requires:
  1. Adding the field to the MailConfig class.
  2. Adding a new entry to the ATTRIBUTE_SETTERS map.
• Clean handling of special logic: Attributes that need parsing, validation, or complex transformations can have their logic encapsulated directly in the map's lambda function, keeping it isolated from other code.
• Consistent error handling: You can add a universal handler for unknown attributes (logging, throwing exceptions, etc.) without modifying multiple if blocks.

Bonus: Making It Even More Maintainable #

If you expect a lot of attributes or very complex logic, you could take this a step further:

• Extract each attribute's handler into a separate class (following the Strategy Pattern) for even better separation of concerns.
• Load the attribute mappings from a configuration file (though that's overkill for most cases).

内容的提问来源于stack exchange，提问作者Al Phaba