生成相同结果但参数不同的函数适用何种设计模式？

Hey there! Let's work through your problem step by step—you've got a messy 1000+ line codebase split into a dozen methods that all spit out FinancialTransactionObjects (just with different dates, amounts, and params), and you want to wrap each method into its own class that inherits from a single-method base/interface. The catch is you can't reuse instances via constructors. Here's the perfect pattern combo for this:

This pair addresses both your encapsulation goal and the instance reuse problem. Let's break it down:

1. Factory Method: Encapsulate Each Transaction Generation Logic #

First, define an abstract base interface (or class) that declares the core method for creating your transaction objects. Let's call it TransactionGenerator:

public interface TransactionGenerator {
    FinancialTransactionObject generateTransaction();
}

Now, turn each of your original methods into a concrete implementation of this interface. Each class will handle its specific parameter setup—you can pass required values (like dates/amounts) via the class constructor or set them as public properties (constructor injection is cleaner for mandatory params).

Example implementation for a salary transaction:

public class SalaryTransactionGenerator implements TransactionGenerator {
    private final LocalDate payDate;
    private final BigDecimal salaryAmount;
    private final String employeeId;

    // Inject required params via constructor
    public SalaryTransactionGenerator(LocalDate payDate, BigDecimal salaryAmount, String employeeId) {
        this.payDate = payDate;
        this.salaryAmount = salaryAmount;
        this.employeeId = employeeId;
    }

    @Override
    public FinancialTransactionObject generateTransaction() {
        // This is where your original salary method logic lives
        FinancialTransactionObject transaction = new FinancialTransactionObject();
        transaction.setTransactionDate(payDate);
        transaction.setAmount(salaryAmount);
        transaction.setType("SALARY");
        transaction.setRelatedId(employeeId);
        // Add any other property setup specific to salary transactions
        return transaction;
    }
}

This keeps each transaction type's logic isolated, makes your code easier to test, and lets you add new transaction types later without touching existing code (hello, Open/Closed Principle!).

2. Prototype Pattern: Fix the "Can't Reuse Instances via Constructor" Problem #

You mentioned constructors can't reuse instances—this is exactly what the Prototype Pattern solves. Instead of creating a brand new FinancialTransactionObject via constructor every time, you clone an existing prototype instance and tweak its parameters.

First, add cloning capability to your FinancialTransactionObject:

public class FinancialTransactionObject implements Cloneable {
    private LocalDate transactionDate;
    private BigDecimal amount;
    private String type;
    private String relatedId;

    // Constructor, getters, setters...

    @Override
    public FinancialTransactionObject clone() {
        try {
            // Shallow clone works here if all properties are immutable (like LocalDate, BigDecimal)
            return (FinancialTransactionObject) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new RuntimeException("Failed to clone transaction object", e);
        }
    }
}

Now update your factory implementations to use cloning instead of newing up objects. You can even have a shared prototype instance (e.g., a base transaction with default values) that all factories clone and modify:

// Assume we have a shared prototype (could be injected or created once)
private static final FinancialTransactionObject BASE_TRANSACTION_PROTOTYPE = new FinancialTransactionObject();

@Override
public FinancialTransactionObject generateTransaction() {
    // Clone the prototype instead of calling the constructor
    FinancialTransactionObject transaction = BASE_TRANSACTION_PROTOTYPE.clone();
    // Override only the params specific to this transaction type
    transaction.setTransactionDate(payDate);
    transaction.setAmount(salaryAmount);
    transaction.setType("SALARY");
    transaction.setRelatedId(employeeId);
    return transaction;
}

This way, you're reusing the prototype's structure instead of creating a new object from scratch every time, which avoids the constructor reuse limitation you mentioned.

Bonus: Builder Pattern for Complex Parameter Sets #

If your FinancialTransactionObject has tons of optional parameters, pairing this with the Builder Pattern can make your code even cleaner. Add a builder inner class to your transaction object:

public class FinancialTransactionObject {
    private final LocalDate transactionDate;
    private final BigDecimal amount;
    private final String type;
    private final String relatedId;

    // Private constructor only accessible to the builder
    private FinancialTransactionObject(Builder builder) {
        this.transactionDate = builder.transactionDate;
        this.amount = builder.amount;
        this.type = builder.type;
        this.relatedId = builder.relatedId;
    }

    public static class Builder {
        // Required params (no default)
        private final LocalDate transactionDate;
        private final BigDecimal amount;
        // Optional params (with defaults)
        private String type = "GENERAL";
        private String relatedId = "";

        public Builder(LocalDate transactionDate, BigDecimal amount) {
            this.transactionDate = transactionDate;
            this.amount = amount;
        }

        public Builder type(String type) {
            this.type = type;
            return this;
        }

        public Builder relatedId(String relatedId) {
            this.relatedId = relatedId;
            return this;
        }

        public FinancialTransactionObject build() {
            return new FinancialTransactionObject(this);
        }
    }
}

Then your factory method can use the builder to create instances cleanly, even with optional params:

@Override
public FinancialTransactionObject generateTransaction() {
    return new FinancialTransactionObject.Builder(payDate, salaryAmount)
            .type("SALARY")
            .relatedId(employeeId)
            .build();
}

Why This Works for You #

• Factory Method keeps your transaction generation logic decoupled and scalable—each transaction type is its own class, making debugging and testing a breeze.
• Prototype Pattern solves your constructor reuse issue by letting you clone existing instances instead of creating new ones from scratch.
• Optional Builder Pattern cleans up complex parameter setup if your transaction objects have lots of optional fields.

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