In the company I work for, I keep seeing IManager interfaces being converted into their real types and lots of "instanceof / TypeOf" if statement checks.

For example:

IManager manager // passed to method as a parameter

if (manager.GetType() == typeof(CustomerManager)) {
    customerManager = (CustomerManager) manager;
    customers = customerManager.GetCustomers();
    groupId = customerManager.GetCustomerGroupID(); 
    // etc...

I've been reading Liskov Substitution Principle and it states that "Subtypes must be substitutable for their base type". This seems to violate this.

The sub-types have their own very specific functions and I'm not sure on how to solve this. This is a problem I see happen a lot when I myself am developing. I find it hard to avoid and I think I need to change how I treat interfaces.

Does anyone have any SE advice to avoiding common problems like this?

1 Answer 1


If you're passing interfaces around to places that can't get their work done with only the functions in the interfaces, then you shouldn't be using those interfaces in the first place.

Often such code is the result of people slavishly following the principle "Code to interfaces, not to implementations", without understanding the even more important principle "If you use instanceof, refactoring to use interfaces is pointless".

An interface is useful if multiple concrete classes are interchangable for some particular purpose. If they aren't, well, there's no shame in that. Perhaps you can group your functionality in a different way so that some things can be abstracted away. But mandating the use of interfaces in situations where they don't work is a red flag; it means that someone understands important principles only half-way.

  • My boss says "code to interfaces" a lot. Makes sense! I like to use interfaces as a way of configuring objects through composition. I don't like seeing interfaces used as a way of grouping together unrelated classes like this. Just because they are both "Manager" classes does not mean they are functionally similar.
    – Mayron
    Commented Feb 13, 2018 at 10:44
  • 2
    @Mayron: What a lot of people also misunderstand is that "code to interfaces" does not even refer to the interface keyword of Java/C#. It primarily means that the user of a class should not care about how the public methods are implemented. Commented Feb 13, 2018 at 10:59
  • This is all true, but it should be noted that interfaces (Bart makes an important distinction) are used as a means to provide some meaning to APIs which warrant unions in languages which don't have unions: you know you need a manager, so you only accept a type which declares itself to be a manager. There is obviously nothing ideal about this, but it's better than nothing. Commented Feb 13, 2018 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.