Why Code Reuse Matters When Integrating with Low‑Code Platforms

Duplicate Code Before Refactoring

Each business method that updates or adds records to the low‑code platform repeats the same 20–40 lines: constructing a GatewayRequestDTO, setting configId and externalSystem, building a data map with worksheetId and workflow flags, adding each field name/value pair to a controls list, setting request headers, invoking the gateway, and parsing the response for success.

GatewayRequestDTO request = new GatewayRequestDTO();
request.setConfigId(configId);
request.setExternalSystem("lowcode");
// construct controls, dataMap, requestBizData, requestHeaders…
gatewayService.request(request);

If the low‑code API changes, every scattered method must be updated, and a missed change can cause production failures.

Programmers who truly value reuse embed it in their DNA; lacking this mindset warrants self‑reflection.

Design of Two Generic Methods

Two generic methods—one for updating and one for adding rows—encapsulate the invariant parts (DTO construction, external system setting, header logic, gateway call, response parsing) and expose the variable parts (target table, fields, application, workflow trigger, business description) as parameters.

Invariant parts include the way a GatewayRequestDTO is built, the externalSystem value, header construction, gateway invocation, and success‑check logic; these are identical across all business scenarios.

Variable parts include which table to operate on, which fields to update or insert, which low‑code application is involved, whether to trigger a workflow, and a free‑form business‑scenario description for logging.

The key design decision is abstracting fieldName and fieldValue into a DTO because low‑code table fields are dynamically configured and cannot be known at compile time.

public class LowCodeTableFieldDTO {
    public String fieldName;
    public String fieldValue;
}

Callers pass a List<LowCodeTableFieldDTO> containing the desired field‑value pairs; the generic method converts the list into the required controls structure. An enum LowCodeAppEnum constrains the application identifier, preventing accidental misuse.

Encapsulated Calls

After encapsulation, callers only need to specify the table, fields, and context. Example for updating a single field after a refund audit:

lowCodeClient.updateLowCodeTableFieldValue(
    "Update refund audit status",
    "refundTable",
    bizId,
    LowCodeAppEnum.B,
    List.of(new LowCodeTableFieldDTO("refundStatus", "审核通过")));

Example for updating multiple fields after a picking order is shipped:

lowCodeClient.updateLowCodeTableFieldValue(
    "Sync picking order status",
    "pickingTable",
    rowId,
    LowCodeAppEnum.B,
    List.of(
        new LowCodeTableFieldDTO("orderStatus", "已发货"),
        new LowCodeTableFieldDTO("shippingTime", "2024-01-15 10:30:00")));

Adding a new row (e.g., initial warehouse data sync) uses addLowCodeRow, which returns the newly created row ID for later updates.

Where previously each business method contained 20–40 lines of duplicated code, the encapsulated approach reduces the caller to a few lines focused on business intent.

Conclusion

Code reuse is valuable not merely for saving a few dozen lines but for clearly separating knowledge domains: the low‑code API details are hidden inside the generic methods, freeing callers from implementation specifics.

When three or more methods share the same request‑construction skeleton (building the request, setting parameters, invoking the API, parsing the response), it signals that a generic method should be extracted. This concrete signal is more actionable than the abstract DRY principle.