我已经有几十年没有重温四人帮了。我最近从一些代码中感受到了不好的味道，并且正在寻找有关优化设计的建议。
存在一个通过接受二进制上传、对其执行各种处理并存储文件来为 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)
布尔值对应于包装函数相关部分的新添加的条件。该函数有多种途径，因此每次添加新的布尔值时，都需要重新访问所有调用代码。此外，代码的自我记录能力也越来越差。这是一个地方的示例：
ro = uploadThing(user_id, org_id, file_bytes, true, false, true)
如果任何与布尔相关的代码实际被触发，则执行顺序至关重要。此外，其他参数中不包含可用于确定要执行 uploadThing 方法的哪些部分的信息 - 它纯粹基于特定调用代码的位置。
我不喜欢这一点的一些事情：调用者和被调用者之间的耦合越来越紧密，越来越多地需要覆盖重构中的多个点，以及方法调用在被调用时的预期行为越来越模糊。你将如何重组这个？