Interface & Base Abstract Class c#

Question

Is it good practice to define an interface, implement the interface in a base abstract class, give it default behavior and then inherit from the base class?

Or it that overkill?

Answer 1

Whether to use an interface or an abstract class are two entirely different questions. It might happen that the answer to both is yes but one has nothing to do with the other.

Unless you're absolutely certain that you're going to need multiple classes that inherit from a base class and share certain methods, I wouldn't plan up front to use inheritance. When we start off envisioning some perfect textbook class hierarchy it often gets complicated and doesn't work out. It often makes more sense when you're refactoring or if you find yourself writing a similar class and don't want to duplicate code.

Writing an interface and then implementing it is a good practice when you're creating something that another class is going to depend on (which is very often.) For example, if you know that your class is going to depend on another class that "does something" then you can momentarily pause working on the first class to write the IDoesSomething interface, and finish the first class that depends on IDoesSomething . You haven't figured out what the implementation is yet, but it doesn't matter because the class you're already writing just depends on the interface. (Inversion of Control - good practice.) Then you can write a class that implements IDoesSomething .

Just to expound on that with an example. Suppose I'm writing a class that provides a Menu object which contains a nested list of MenuItem objects:

public class MenuProvider
{
    public Menu GetMenu(string menuId)
    {
        //code that gets the menu
        return menu;
    }
}

Then I realize that I'm going to need to filter out certain menu items before returning it. That might be based on configuration settings, the particular user, or anything else.

I might write this interface:

public interface IMenuFilter
{
    void FilterMenu(Menu menu);
}

and then modify my original class like this:

public class MenuProvider
{
    private readonly IMenuFilter _menuFilter;

    public MenuProvider(IMenuFilter menuFilter)
    {
        _menuFilter = menuFilter;
    }

    public Menu GetMenu(string menuId)
    {
        //code that gets the menu

        //filter the menu
        _menuFilter.FilterMenu(menu);
        return menu;
    }
}

I don't know what the implementation of IMenuFilter is going to be. In practice it might end up being a composite of a bunch of separate classes that each perform one type of filtering. But the point is that I don't need to stop what I'm doing on MenuProvider to figure that out. I can write this class and even test it with a mocked IMenuFilter , and then move on to write the specifics of that filter.

Answer 2

Do you have common functionality that you want to share amongst implementations of this interface? If so, then create an abstract base class. Otherwise, don't worry about it now. You can always add one later. But programming to interfaces is almost always a good idea.

Answer 3

Generally, you will use either an interface or inheritance. I don't normally don't use both with the same class.

Use inheritance when you want to inherit functionality from the base class.

Use an interface when you want disparate classes to implement some same core functionality, but not necessarily share code.