Overrloading methods in Java interface

Question

Is it right to overload method in Java interface like below. And then use the method required in your subclass? If not, is there a better way to do it, kindly suggest.

interface IEmployees{
    public List<String> getEmployees(List<String> employees, List<String> departments);
    public List<String> getEmployees(List<String> employees, String name);
} 

class EmployeesByDept implements IEmployees{
    public List<String> getEmployees(List<String> employees, List<String> departments){
        // select employees belonging to depts in list and return.
    }
    public List<String> getEmployees(List<String> employees, String name){
         throw new UnsupportedOperationException();
    } 
}

class EmployeesByName implements IEmployees{
    public List<String> getEmployees(List<String> employees, List<String> departments){
        throw new UnsupportedOperationException();
    }
    public List<String> getEmployees(List<String> employees, String name){
        // select employees with name in list and return.
    }
}

Answer 1

in my opinion overloading an interface this way is not a good idea, as this produces unnecessary/useless code at the implementing class.

I would therefore recommend to write 2 or 3 different interfaces like so

interface IEmployees {
}

interface IEmployeesByDept extends IEmployees {
    public List<String> getEmployees(List<String> employees, List<String> departments);
}

interface IEmployeesByName extends IEmployees {
    public List<String> getEmployees(List<String> employees, String name);
}

This Way you can cleanly implement the interface that matches your case.

Answer 2

Well, yes and no, it depends.

In general there are most certainly cases for it, where appropriate.

In your case though, probably not, and a lot of your issue comes down to more fundamental design problems. So just by reading your snippet it appears the possibilities are that an IEmployees is:

1. A set of all employees in a system (for example, all of the employees that work on a project or for a company), or
2. An arbitrary list of employees (includes 1 but also e.g. search results, etc., the semantic equivalent of a List<Employee>, or
3. A construct that has a list of employees associated with it (for example, a project, or an organization).

But you say:

it is actually an employee filter class. It will be inherited by other filter classes and will implement any one of the overloaded methods in the interface.

So your first minor problem is the interface name itself. IEmployees leaves a lot up in the air, but if you name it something more self-documenting and descriptive, e.g. IEmployeeFilter, then things start to come together a little more obviously.

So now you have a "filter", and it appears you are trying to have multiple separate filter strategies:

• By department
• By employee name
• Possibly others

These are separate filters, and you state your interface defines a filter, and therefore these are more appropriately organized as two separate subclasses.

So first of all the interface should be what is common to all filters. How the filtering is done is not the common aspect. The filtering itself is. So consider:

interface IEmployeeFilter {
    public List<String> getEmployees (List<String> employees);
}

Now you have a filter that makes sense, a single common method, and everything else falls into place, e.g.:

class EmployeeNameFilter implements IEmployeeFilter {

    private String name;

    public EmployeeNameFilter (String name) { 
        this.name = name; 
    }

    @Override
    public List<String> getEmployees (List<String> employees) {
        return employees filtered appropriately
    }

}

And:

class EmployeeDepartmentFilter implements IEmployeeFilter {

    private List<String> departments;

    public EmployeeDepartmentFilter (List<String> departments) { 
        departments = new ArrayList<String>(departments);
    }

    @Override
    public List<String> getEmployees (List<String> employees) {
        return employees filtered appropriately
    }

}

Etc. Then when you're ready to use one the interface is always the same:

List<String> employees = ...;
IEmployeeFilter filter = new EmployeeNameFilter("bob"); // or...
// IEmployeeFilter filter = new EmployeeDepartmentFilter(...);

List<String> results = filter.getEmployees(employees); // <- interface always the same

Point is, interfaces exist as a tool to make a job easier. When you run into a situation where you have a bunch of classes implementing that interface but they all implement different parts of it, you're starting to defeat the purpose of an interface, and it's a good hint that there's a fundamental change that needs to be made in your design.

That is, a more general rule of thumb can be: If your interface is making your job harder, or making your code more complicated, you've done something wrong. Otherwise, you've done something right.

Hope that made sense.

Answer 3

Your use-case does not warrant the use of an Interface at all

An Interface represents a contract. You defined the contract as being able to fulfill two requirements. If you know you won't be able to provide both parts of the contract, do not use an interface at all.

Additionally, I strongly doubt you have alternative ways of getting these Employees Lists, another reason not to use interfaces.

Alternative solution

I am guessing your IEmployeesXXX classes have no state variable. This is a good indicator that the methods are utility methods which fetch and return a list of objects.

You should make it a classic Utility class, i.e. an abstract final class with static methods.

Here's an example using your own code, wich becomes much cleaner:

public abstract final class Employeesutility{
    public static List<String> getEmployees(List<String> employees, List<String> departments){
        // select employees belonging to depts in list and return.
    }
    public static List<String> getEmployees(List<String> employees, String name){
        // select employees with name in list and return.
    }
}

Notes going forward

I do not like Utility classes much, I would rather make an intermediate class with rich internal representation, and rich collections wich expose your proposed interface methods. But for your use case, this would probably mean duplicate the entire DB (guessing you have one), which would be stupid. Please consider it if ever you decide to create a true Employee class... which you will when your program becomes big enough.