Define two methods with same parameter type

Question

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

Answer 1

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

Answer 2

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.

Answer 3

Maintaining readability is precisely why you should rename it:

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.

Answer 4

Define 2 methods:

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

Answer 5

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.