定义两个具有相同参数类型的方法

发布于 2024-11-26 19:02:41 字数 547 浏览 1 评论 0原文

今天我遇到了一个场景,我必须创建一个与现有方法共享相同名称、参数计数和参数类型的方法,如下所示:

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

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

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

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

此案例的最佳实践是什么?我看到了所有可以让我的代码运行的方法,但没有一个让我满意

Today I ran into a scenario where I have to create a method that share the same name, params count and params types with existent one, Something like this:

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

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

at first glance I just said why not to name it with a different name and get things done, but I couldn't! I do want to maintain the readability of my code i'm working on, I want it to be overloaded to the first one,
so I said why not to add a fake parameter just to workaround this issue from the compiler Point of view.

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

What is the best practice for this case? I see all the ways can let my code run, but none of them satisfied me

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

月下伊人醉 2024-12-03 19:02:41

保持可读性正是您应该重命名它的原因:

// Even if the parameter types are enough to distinguish
// between the two, this is ambiguous when reading.
Department GetDepartment(...)

// These two are clear at the call site.
Department GetDepartmentByName(...)
Department GetDepartmentByEmployeeId(...)

现在,无论您何时调用该方法,您所指的方法都绝对明显。如果您重载该方法,情况就完全不同了。

随着时间的推移,我变得越来越不愿意超载 - 有相当多的微妙问题 ,并且可读性经常下降。

Maintaining readability is precisely why you should rename it:

// Even if the parameter types are enough to distinguish
// between the two, this is ambiguous when reading.
Department GetDepartment(...)

// These two are clear at the call site.
Department GetDepartmentByName(...)
Department GetDepartmentByEmployeeId(...)

Now whenever you call the method, it's absolutely obvious which one you mean. That's very much not the case if you overload the method instead.

I've become increasingly reluctant to overload over time - there are quite a few subtle issues, and readability very often goes down.

七堇年 2024-12-03 19:02:41

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

public static GetDepartmentByName( string departmentName )

public static GetDepartmentByEmployeeId( string employeeId )

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

You could update your method signatures and make your code more readable at the same time by doing something like the following.

public static GetDepartmentByName( string departmentName )

public static GetDepartmentByEmployeeId( string employeeId )

Personally I feel that adding verbosity to code helps others that come later understand what's going on. It also helps make your methods "read" more easily.

梦旅人picnic 2024-12-03 19:02:41

定义2个方法:

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

Define 2 methods:

  1. public static Department GetDepartmentByDepartmentName(string departmentName)
  2. public static Department GetDepartmentByEmployeeID(string employeeID)
终弃我 2024-12-03 19:02:41

如果您可以通过检查参数以某种方式区分员工 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% 正确。

Another option would be to delegate to other methods if you can somehow distinguish between an employee ID and a department name by examining the argument.

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) {
    /* ... */
}

You should only do this if you absolutely cannot add another method for clarity - the other answers are 100% on point.

回忆凄美了谁 2024-12-03 19:02:41

有点晚了,但有可能,我今天遇到了完全相同的情况(构造函数重载,因此无法更改名称)。这是我的做法,虽然是个小技巧,但它让我可以将所有相关的 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);

A bit late but it is possible, I had the exact same scenario today (constructor overloading, thus can't change name). Here is how I did it, small hack but it lets me have all my LINQ predicates that are related in the same place:

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();
}

Now the trick is to call them using parameter names like so:

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

if (!responsibiltyTypeId.HasValue && userId.HasValue)
    spec = new BusinessStructureFilterSpecification(userId: userId.Value);
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文