Mastering Java Boilerplate: Definitions, Patterns, and Reduction Techniques

Introduction

Drawing inspiration from Shen Kuo’s description of movable type printing, the article likens reusable code snippets to printing characters, emphasizing that copying and adapting such "type" dramatically speeds up development.

What Is Boilerplate Code?

Boilerplate code (or template code) refers to fixed‑pattern code blocks that can be widely reused across different modules, such as file‑reading logic or getter/setter methods.

Typical Boilerplate Example

try (BufferedReader reader = new BufferedReader(new FileReader(fileName))) {
    String line;
    while (Objects.nonNull(line = reader.readLine())) {
        // process a line
        ...
    }
} catch (IOException e) {
    String message = String.format("读取文件(%s)异常", fileName);
    log.error(message, e);
    throw new ExampleException(message, e);
}

Benefits of Boilerplate

Provides a standard example for newcomers to learn quickly.

Offers ready‑made solutions for similar scenarios.

Helps accumulate experience and improve code quality.

Reduces bugs because the code has been battle‑tested.

Accelerates coding speed through copy‑paste modification.

Ensures consistent coding style across a project.

How to Write Boilerplate

Boilerplate can be created by copying existing snippets, using text replacement, Excel formulas, IDE plugins, or code‑generating scripts.

Ways to Reduce Boilerplate

Use Lombok annotations such as @Getter and @Setter to generate accessor methods.

Leverage frameworks (e.g., MyBatis) that encapsulate repetitive JDBC code.

Apply design patterns like the Template Method to encapsulate common logic.

Adopt builder patterns for complex object construction.

Utility Class Definition

A typical utility class may look like:

/** Example helper */
public class ExampleHelper {
    /** Constant value */
    public static final int CONST_VALUE = 123;
    /** Sum method */
    public static int sum(int a, int b) {
        return a + b;
    }
}

Issues include non‑standard modifier order and the possibility of inheritance or instantiation. The recommended best practice is to make the class final, add a private constructor that throws UnsupportedOperationException, and keep all members static.

Enum Definition

/** Example enum */
public enum ExampleEnum {
    ONE(1, "one(1)"),
    TWO(2, "two(2)"),
    THREE(3, "three(3)");

    private final int value;
    private final String desc;

    private ExampleEnum(int value, String desc) {
        this.value = value;
        this.desc = desc;
    }

    public int getValue() { return value; }
    public String getDesc() { return desc; }
}

Best practices: use primitive types, mark fields as final, and avoid unnecessary private modifiers on constructors.

Model Class Definitions

JavaBean style with private fields and public getters/setters; simple but mutable.

public class User {
    private Long id;
    private String name;
    private Integer age;
    private String desc;
    // getters and setters
}

Overloaded Constructors provide immutable instances but can lead to many constructors and reduced readability.

public final class User {
    private final Long id;
    private final String name;
    private final Integer age;
    private final String desc;
    public User(Long id, String name) { this(id, name, null, null); }
    public User(Long id, String name, Integer age) { this(id, name, age, null); }
    public User(Long id, String name, Integer age, String desc) { /* validations */ }
}

Builder Pattern clarifies required vs optional parameters and yields immutable objects, at the cost of extra code and runtime overhead.

public final class User {
    private final Long id;
    private final String name;
    private final Integer age;
    private final String desc;
    private User(Builder b) { ... }
    public static Builder newBuilder(Long id, String name) { return new Builder(id, name); }
    public static class Builder {
        private Long id; private String name; private Integer age; private String desc;
        private Builder(Long id, String name) { /* validations */ }
        public Builder age(Integer age) { this.age = age; return this; }
        public Builder desc(String desc) { this.desc = desc; return this; }
        public User build() { return new User(this); }
    }
}

Collection Constants

Defining mutable collections as static final does not guarantee immutability. The recommended approach uses Collections.unmodifiableList/Set/Map to create true constants.

public final class ExampleHelper {
    public static final List<Integer> CONST_VALUE_LIST =
        Collections.unmodifiableList(Arrays.asList(1, 2, 3));
    public static final Set<Integer> CONST_VALUE_SET =
        Collections.unmodifiableSet(new HashSet<>(Arrays.asList(1, 2, 3)));
    public static final Map<Integer, String> CONST_VALUE_MAP;
    static {
        Map<Integer, String> m = new HashMap<>();
        m.put(1, "value1"); m.put(2, "value2"); m.put(3, "value3");
        CONST_VALUE_MAP = Collections.unmodifiableMap(m);
    }
}

Array Constants

Public array fields are mutable. The safe pattern is a private array with a public method returning a cloned copy.

public final class ExampleHelper {
    private static final int[] CONST_VALUES = {1, 2, 3};
    public static int[] getConstValues() { return CONST_VALUES.clone(); }
}

Multi‑Condition Expressions

Complex if statements with many && conditions increase cyclomatic complexity. Strategies to simplify include:

Breaking the condition into separate boolean variables.

Using a list of BooleanSupplier objects added dynamically (may affect performance).

Staticizing the list with Predicate<Data> objects to avoid runtime construction.

Each approach reduces readability and/or performance trade‑offs, and the article discusses their pros and cons.