How to Eliminate Duplicate Code with Factory & Template Method Patterns in Java

Why Duplicate Code Is Dangerous

Many CRUD engineers feel their work lacks technical depth because they rarely use design patterns or high‑concurrency techniques, leading to repetitive code that is hard to maintain. Duplicate code can cause bugs when a change is missed in one place, introduce subtle errors when similar code is edited inconsistently, and increase the risk of incorrect logic across many methods.

Factory + Template Method Refactoring

To handle three different cart behaviours (normal user, VIP user, internal user) without duplicating initialization, total price, shipping, and discount calculations, the article extracts the common workflow into an abstract class AbstractCart and defines two abstract methods for the variable parts: processCouponPrice – calculates product discounts. processDeliveryPrice – calculates shipping fees.

The three concrete carts extend AbstractCart and implement only the specific logic:

NormalUserCart – 0 discount, 10% shipping.

VipUserCart – inherits normal logic and overrides the multi‑buy discount.

InternalUserCart – free shipping and no discount.

Annotation + Reflection Refactoring

The article then tackles a banking API that requires fixed‑length, left‑padded strings for text fields, right‑padded zeros for numbers, and special handling for monetary values. Instead of hard‑coding each parameter, it defines POJO classes ( CreateUserAPI, PayAPI) annotated with a custom @BankAPI (URL and description) and @BankAPIField (order, type, length).

public class CreateUserAPI {
    private String name;
    private String identity;
    private String mobile;
    private int age;
}

A generic remoteCall(AbstractAPI api) method uses reflection to:

Read the @BankAPI annotation for the endpoint URL.

Collect all fields annotated with @BankAPIField, sort them by order, and make them accessible.

For each field, retrieve its value, format it according to its type (S‑string, N‑number, M‑money), pad appropriately, and append to a StringBuilder.

Append an MD5 signature and send the request via HTTP.

Property Copy Issues

When converting between DTO, DO, and VO objects in a three‑layer architecture, manual field‑by‑field assignment quickly becomes error‑prone, especially with dozens or hundreds of properties. The article shows a typical buggy snippet where fields are mismatched or copied from the wrong object.

ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO();
ComplicatedOrderDO orderDO = new ComplicatedOrderDO();
orderDO.setCommentable(orderDTO.isComplainable()); // swapped
orderDO.setDeliveryManMobile(orderDO.getDeliveryManMobile()); // self‑reference

Using a mapping utility such as BeanUtils.copyProperties with an ignore list can automate this process and reduce mistakes.

Conclusion

Duplicate code inevitably leads to bugs. The recommended strategies are:

Extract common logic into a superclass and use the Template Method pattern for variations.

Replace hard‑coded rule implementations with custom annotations and reflection to separate rule data from processing code.

Leverage bean‑mapping tools for DTO/DO conversions and add unit tests to verify field mappings.

By applying these techniques, projects can achieve better maintainability, extensibility, and adherence to the Open/Closed principle.