根据干净的代码实践制作一个包装方法只是为了可读性可以吗？使用包装器方法这个示例是否更具可读性？ [已关闭]

Question

在其中一个流程中，我们有太多如下所示的回报：

PaymentResponse<ProviderReservedAccountsResponse>.Failed(
    new Error(
        ErrorCode.ReservedAccountsCreationInProgress.ToString(), 
        ErrorCode.ReservedAccountsCreationInProgress.GetDescription()),                       
    (int)HttpStatusCode.TooManyRequests);

每次都有不同的ErrorCode，例如：

• return PaymentResponse<ProviderReservedAccountsResponse>.Failed(
      new Error(ErrorCode.ProviderError.ToString(), ErrorCode.ProviderError.GetDescription()),
      (int)HttpStatusCode.BadRequest);
  

• return PaymentResponse<ProviderReservedAccountsResponse>.Failed(
      new Error(ErrorCode.CustomerNinNotFound.ToString(), ErrorCode.CustomerNinNotFound.GetDescription()),
      (int)HttpStatusCode.BadRequest);
  

我觉得为它们制作一个包装方法可能会更具可读性，让它们看起来更容易一些。根据干净的代码实践，创建它有意义还是多余？

我想的包装方法是这样的：

FailedResponse(ErrorCode.CustomerNinNotFound, HttpStatusCode.BadRequest);

定义为：

private PaymentResponse<ProviderReservedAccountsResponse> FailedResponse(ErrorCode errorCode, HttpStatusCode statusCode) =>
    PaymentResponse<ProviderReservedAccountsResponse>.Failed(
        new Error(errorCode.ToString(), errorCode.GetDescription()),
        (int)statusCode);

Answer 1

是的，使用像

FailedResponse

这样的包装方法可以通过简化重复的错误处理代码来增强可读性和可维护性。