【问题标题】:Define two methods with same parameter type定义两个具有相同参数类型的方法
【发布时间】:2011-10-15 02:08:02
【问题描述】:

今天我遇到了一种情况,我必须创建一个与现有方法共享相同 name, params count and params types 的方法,如下所示:

public static Department GetDepartment(string departmentName)
{
  //LOGIC
}

public static Department GetDepartment(string employeeID)
{
  //LOGIC
}

乍一看,我只是说为什么不给它起一个不同的名字并把事情做好,但我做不到!我确实想保持我正在处理的代码的可读性,我希望它是overloaded 第一个,
所以我说为什么不添加一个假参数只是为了从编译器的角度解决这个问题。

 public static Department GetDepartment(string employeeID, object fakePassWtEver)
    {
      //LOGIC
    }

这种情况的最佳做法是什么?我看到了所有可以让我的代码运行的方法,但没有一个让我满意

【问题讨论】:

  • 假参数的想法真的很糟糕......拥有多个具有相同名称的方法参数类型应该不同,你可以有一个字符串和一个对象,但这也不好,因为每次您将传递一个不会调用带有 object 的字符串...正如 Jon 建议的那样,始终使用两个不同的方法名称,您不能拥有适当不同的参数类型...
  • 投反对票对我来说是可以的,因为它与评论相关联!问你的想法有错吗..

标签: c# .net methods parameters overloading


【解决方案1】:

保持可读性正是为什么你应该重命名它:

Department GetDepartmentByName(...)

Department GetDepartmentByEmployeeID(...)

现在,无论何时调用该方法,一目了然您指的是哪个方法。如果您改为重载方法,则情况非常不是

随着时间的推移,我越来越不愿意超载 - 有 quite a few subtle issues,可读性经常下降。

【讨论】:

  • 这当然是正确的答案,但稍微解释一下可能会有所帮助,这样他就会明白为什么会像你说的那样。
  • @jnm2:您认为哪一点不清楚?需要说明什么? GetDepartmentByName(value)GetDepartment(value) 含义更清晰不是很明显吗?
  • 认为这是不言自明的,但他可能不会。我记得几年前的某个时候,这对我来说根本不明显。问题是,并不是每个人都天生就有这些本能——总有第一次。因此,由于我不了解他的背景,我会确保我的回答会对更广泛的受众有所帮助。就此而言,强化概念并没有什么坏处。但这只是我。我在这里可能完全错了。
  • @jnm2:但老实说,我不确定如何才能更清楚地说明......哪一点对你来说不是很明显,已经很明显了吗?我全力支持在可能的情况下改进答案...
  • 自我第一次发表评论以来您所做的编辑更有帮助,因为它引起了人们对为什么第一个示例好而第二个示例不好的原因的关注。与我对可读性的看法类似,我完全支持让人们更容易理解和记忆。如果我问过,我可能希望听到更多关于如果你以错误的方式做事会发生什么的事情,这样原则就会变得更加直观。否则我可能会继续觉得我仍然更喜欢它,这会影响我的决定。这有点像“看到”数学,而不仅仅是掌握事实。
【解决方案2】:

您可以通过执行以下操作来更新您的方法签名并同时使您的代码更具可读性。

public static GetDepartmentByName( string departmentName )

public static GetDepartmentByEmployeeId( string employeeId )

就我个人而言,我觉得在代码中添加冗长有助于后来的其他人理解发生了什么。它还有助于使您的方法更容易“阅读”。

【讨论】:

    【解决方案3】:

    定义2个方法:

    1. public static Department GetDepartmentByDepartmentName(string departmentName)
    2. public static Department GetDepartmentByEmployeeID(string employeeID)

    【讨论】:

      【解决方案4】:

      如果您可以通过检查参数以某种方式区分员工 ID 和部门名称,则另一种选择是委托给其他方法。

      public static Department GetDepartment(string employeeIdOrDepartmentName) {
          if (LooksLikeEmployeeID(employeeIdOrDepartmentName))
              return GetDepartmentByEmployeeID(employeeIdOrDepartmentName);
          else
              return GetDepartmentByDepartmentName(employeeIdOrDepartmentName);
      }
      
      private static Department GetDepartmentByEmployeeID(string employeeId) {
          /* ... */
      }
      
      private static Department GetDepartmentByDepartmentName(string departmentName) {
          /* ... */
      }
      

      只有在您绝对不能添加其他方法以明确起见时,您才应该这样做 - 其他答案是 100% 正确的。

      【讨论】:

      • 我想知道什么时候会出现。这个模型可以很好地解释用户输入,但它不应该在内部使用。额外的计算和复杂性将导致代码变慢并且可能出现错误。事实上,解释用户输入应该只在一个地方完成,并不保证在框架中保持自己的功能。也就是说,top 方法不属于其他两种。它属于程序的 UI 部分。
      • 是的,这是“不得已”的解决方案。
      【解决方案5】:

      有点晚了,但有可能,我今天遇到了完全相同的情况(构造函数重载,因此无法更改名称)。这是我的做法,小技巧,但它让我可以将所有相关的 LINQ 谓词放在同一个地方:

      public BusinessStructureFilterSpecification(int responsibilityTypeId, bool dummy1 = true) : base(x => x.ResponsibleGroups.Any(x1 => x1.ResponsibilityTypeId == responsibilityTypeId))
      {
          AddIncludes();
      }
      
      public BusinessStructureFilterSpecification(int userId, string dummy2 = "") : base(x => x.ResponsibleUsers.Any(x1 => x1.UserId == userId))
      {
          AddIncludes();
      }
      

      现在的诀窍是使用参数名称来调用它们,如下所示:

      if (responsibiltyTypeId.HasValue && !userId.HasValue)
          spec = new BusinessStructureFilterSpecification(responsibilityTypeId: responsibiltyTypeId.Value);
      
      if (!responsibiltyTypeId.HasValue && userId.HasValue)
          spec = new BusinessStructureFilterSpecification(userId: userId.Value);
      

      【讨论】:

      • 恕我直言,我会在代码审查中拒绝这种方法。它具有误导性,导致不明显的重载解决方案,并且编译器没有太多帮助来找出代码中断的原因。太 C 加加分了,抱歉。
      • @YurySchkatula 那么你会为完全相同的目的创建一个新类吗?
      • 只是将名称更改为唯一。与 Swift 不同,C# 不会将参数名称等元数据包含在签名中,因此我们必须忍受这一点。
      • @YurySchkatula 这些都是指向基础构造函数的构造函数,遗憾的是我无法更改名称。
      猜你喜欢
      • 2020-11-26
      • 1970-01-01
      • 2020-10-23
      • 2014-11-10
      • 2016-08-10
      • 1970-01-01
      • 1970-01-01
      • 2022-08-18
      • 2019-04-15
      相关资源
      最近更新 更多