如何检查我是否使用子类的实例？

Question

I read an interesting article on the third SOLID principle: https://stackify.com/solid-design-liskov-substitution-principle/

At the same time, I read that using an instanceof operator can be a violation of the SOLID rule. How to deal with the following problem.

I have two classes (pseudo code):

CoffeeMachine {
    brewCoffee();
}

PremiumCoffeeMachine extends CoffeeMachine {
    brewCoffee()
    brewEspresso()
}

Then somewhere in the program I got a collection of coffee machines

Set<CoffeeMachine> coffeeMachines

Now I'd like to make coffee with each of the coffee machines. How will I know I can make an espresso without using an instanceof operator?

Maybe it's the only way, but I read many times today that an instanceof operator breaks the SOLID

Do you know an interesting article or can you provide a solution to such a problem? Maybe II wrong and SOLID says that subclasses should't contains extra methods?

Answer 1

Your given reference gives a lot of insight on how you could deal with this problem.

In the end, you want to iterate over a Collection of CoffeeMachine instances and instruct them to brew coffee, as described by brewCoffee() . And you are correct, to know if your machine is a premium one, you would have to use the instanceof operator.

If you want a more flexible solution, you could use the following design:

public interface CoffeeMachine {

    // check if this machine supports a given selection
    // if not, #brewCoffee should throw an exception
    boolean supports(CoffeeSelection selection);
   
    CoffeeDrink brewCoffee(CoffeeSelection selection);
}

Now, one could imagine a PremiumCoffeeMachine that supports an EspressoCoffee (a special CoffeeSelection ). CoffeeSelection ifself can be an interface , a class or an enum , depending on the complexity and requirements of the different coffees.

Answer 2

instanceof doesn't break SOLID. The idea that is being expressed on the link that you provided is that the contract for brewCoffee SHOULD NOT be stricter in the subclass, as this breaks the contract. And actually Java won't let you do this