我已经有几十年没有接触过四人帮了。我最近从某些代码中闻到难闻的气味，正在寻找有关优化设计的建议。

存在一个函数，它通过接受二进制上传、对其执行各种处理并存储文件来为 API POST 提供服务。随着时间的推移，随着新需求的出现，根据上传的二进制文件的类型，需要跳过该功能中的一些步骤。随着时间的推移，方法签名演变如下:

第一次迭代:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes)

第二次迭代:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure)

第三次迭代:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure, boolean ignore_aws)

第四次迭代:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure, boolean ignore_aws, boolean log_to_airtable)

boolean 值对应于包装函数相关部分的新添加条件。此函数有多个路径，因此每次添加新 boolean 值时，都需要重新访问所有调用代码。此外，代码的自文档化程度越来越低。这里有一个例子:

ro = uploadThing(user_id, org_id, file_bytes, true, false, true)

如果实际触发了任何依赖于 boolean 值的代码，则执行顺序很关键。此外，其他参数中不包含可用于确定要执行 uploadThing 方法的哪些部分的信息 - 它完全基于特定调用代码的位置。

我不喜欢这个的一些事情:调用者和被调用者之间的耦合越来越紧密，在重构中覆盖多个点的需求越来越大，以及方法调用的预期行为在它发生的地方越来越模糊被调用。你会如何重组它？

最佳答案

你有一个伸缩参数反模式的例子。

使用构建器 模式，尤其是在添加功能、可选性和规定时。 示例:旧的 HttpClient、Base64 编码器。

这里的问题是你想要一个瘦 API，甚至可能是生成的。

使用一个类似 map 的参数类:

public ResponseObject uploadThing(UploadParams params)

public class UploadParams {
    private UploadParams() { }

    public static UploadParamsBuilder(long user_id, long location_id) { }

}

class UploadParamsBuilder {
    UploadParams build() { }
    UploadParamsBuilder withFileBytes(byte[] bytes) { }
    ...

引入可能已经在第二次迭代中完成，因为 azure 是额外的附加功能。

关于java - 设计模式问题: removing overuse of boolean function parameters，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/70204567/