Как не нарушить принцип подстановки Лисков с классом, реализующим несколько интерфейсов?

Я знаю, что у меня мог бы быть интерфейс-оболочка, который расширяет оба интерфейса, но тогда я мог бы получить несколько интерфейсов для обслуживания всех возможных перестановок интерфейсов, которые могут быть реализованы одним и тем же классом.

Я подозреваю, что если вы обнаружите, что многие ваши классы реализуют разные комбинации интерфейсов, то либо: ваши конкретные классы делают слишком много; или (менее вероятно) ваши интерфейсы слишком малы и слишком специализированы, до такой степени, что бесполезны по отдельности.

Если у вас есть веская причина для того, чтобы какой-то код требовал что-то, что является одновременно Interface1 и Interface2, тогда обязательно сделайте комбинированную версию, которая расширяет оба. Если вы изо всех сил пытаетесь придумать подходящее имя для этого (нет, не FooAndBar), то это показатель того, что ваш дизайн неверен.

Абсолютно ничего не полагайтесь на кастинг. Его следует использовать только в крайнем случае и обычно только для очень специфических проблем (например, сериализация).

Мой любимый и наиболее часто используемый шаблон дизайна — это шаблон декоратора. Таким образом, большинство моих классов будут когда-либо реализовывать только один интерфейс (за исключением более общих интерфейсов, таких как Comparable). Я бы сказал, что если ваши классы часто/всегда реализуют более одного интерфейса, то это запах кода.

Если вы создаете экземпляр объекта и используете его в той же области, вам следует просто написать

Example example = new Example();

Просто чтобы было ясно (я не уверен, что это то, что вы предлагали), ни при ни при каких обстоятельствах вы не должны никогда писать что-то вроде этого:

Interface1 example = new Example();
if (example instanceof Interface2) {
    ((Interface2) example).someInterface2Method();
}

Ваш класс может прекрасно реализовать несколько интерфейсов и не нарушает никаких принципов ООП. Напротив, он следует принципу разделения интерфейса.

Это сбивает с толку, почему у вас может возникнуть ситуация, когда ожидается, что что-то типа Interface1 предоставит someInterface2Method(). Вот где ваша конструкция неверна.

Подумайте об этом немного по-другому: представьте, что у вас есть другой метод, void method1(Interface1 interface1). Нельзя ожидать, что interface1 также будет экземпляром Interface2. Если бы это было так, тип аргумента должен был бы быть другим. Пример, который вы показали, именно таков, имея переменную типа Interface1, но ожидая, что она также будет иметь тип Interface2.

Если вы хотите иметь возможность вызывать оба метода, тип вашей переменной example должен быть установлен на Example. Таким образом, вы полностью избегаете instanceof и приведения типов.

Если ваши два интерфейса Interface1 и Interface2 не так слабо связаны, и вам часто придется вызывать методы из обоих, возможно, разделение интерфейсов было не такой уж хорошей идеей, или, может быть, вы хотите иметь другой интерфейс, который расширяет оба.

В целом (хотя и не всегда) instanceof проверки и приведения типов часто указывают на некоторые недостатки проектирования ООП. Иногда дизайн подходил для остальной части программы, но у вас был бы небольшой случай, когда проще ввести приведение, чем реорганизовать все. Но, если возможно, вы всегда должны стремиться избегать этого сначала, как часть вашего дизайна.

У вас есть два разных варианта (держу пари, их гораздо больше).

Первый — создать свой собственный interface, который расширяет два других:

interface Interface3 extends Interface1, Interface2 {}

А затем используйте это во всем коде:

public void doSomething(Interface3 interface3){
    ...
}

Другой способ (и, на мой взгляд, лучший) - использовать дженерики для каждого метода:

public <T extends Interface1 & Interface2> void doSomething(T t){
    ...
}

Последний вариант на самом деле менее ограничен, чем первый, потому что универсальный тип T выводится динамически и, таким образом, приводит к меньшей связанности (класс не должен реализовывать определенный интерфейс группировки, как в первом примере).

Основная проблема

Немного подправив ваш пример, чтобы я мог решить основную проблему:

public void DoTheThing(Interface1 example)
{
    if (example instanceof Interface2) 
    {
        ((Interface2) example).someInterface2Method();
    }
}

Итак, вы определили метод DoTheThing(Interface1 example). Это в основном говорит: «Чтобы сделать это, мне нужен объект Interface1».

Но затем в теле вашего метода оказывается, что вам действительно нужен объект Interface2. Тогда почему вы не запросили его в параметрах метода? Совершенно очевидно, что вы должны были попросить Interface2

Здесь вы предполагаете, что любой объект Interface1, который вы получите, также будет объектом Interface2. Это не то, на что можно положиться. У вас могут быть некоторые классы, которые реализуют оба интерфейса, но вы также можете иметь некоторые классы, которые реализуют только один, а не другой.

Нет неотъемлемого требования, согласно которому Interface1 и Interface2 должны быть реализованы на одном и том же объекте. Вы не можете знать (и не полагаться на предположение), что это так.

Если вы не определите неотъемлемое требование и не примените его.

interface InterfaceBoth extends Interface1, Interface2 {}

public void DoTheThing(InterfaceBoth example)
{
    example.someInterface2Method();
}

В этом случае вам потребовался объект InterfaceBoth для реализации Interface1 и Interface2. Поэтому всякий раз, когда вы запрашиваете объект InterfaceBoth, вы можете быть уверены, что получите объект, который реализует как Interface1, так и Interface2, и, таким образом, вы можете использовать методы из любого интерфейса даже без необходимости приведения или проверки типа.

Вы (и компилятор) знаете, что этот метод всегда будет доступен, и нет никаких шансов, что он не сработает.

Примечание. Вы могли бы использовать Example вместо создания интерфейса InterfaceBoth, но тогда вы сможете использовать только объекты типа Example, а не любой другой класс, реализующий оба интерфейса. Я предполагаю, что вы заинтересованы в обработке любого класса, который реализует оба интерфейса, а не только Example.

Дальнейшее рассмотрение проблемы.

Посмотрите на этот код:

ICarrot myObject = new Superman();

Если вы предполагаете, что этот код компилируется, что вы можете сказать мне о классе Superman? Что он явно реализует интерфейс ICarrot. Это все, что вы можете мне сказать. Вы понятия не имеете, реализует ли Superman интерфейс IShovel или нет.

Итак, если я попытаюсь сделать это:

myObject.SomeMethodThatIsFromSupermanButNotFromICarrot();

или это:

myObject.SomeMethodThatIsFromIShovelButNotFromICarrot();

Стоит ли вам удивляться, если я скажу вам, что этот код компилируется? Вы должны это сделать, потому что этот код не компилируется.

Вы можете сказать: «Но я знаю, что это объект Superman, у которого есть этот метод!». Но тогда вы забудете, что вы только сказали компилятору, что это переменная ICarrot, а не переменная Superman.

Вы можете сказать: «Но я знаю, что это объект Superman, который реализует интерфейс IShovel!». Но тогда вы забудете, что вы сказали компилятору только переменную ICarrot, а не переменную Superman или IShovel.

Зная это, давайте вернемся к вашему коду.

Interface1 example = new Example();

Все, что вы сказали, это то, что у вас есть переменная Interface1.

if (example instanceof Interface2) {
    ((Interface2) example).someInterface2Method();
}

Для вас нет смысла предполагать, что этот объект Interface1 также реализует второй несвязанный интерфейс. Даже если этот код работает на техническом уровне, это признак плохого дизайна, разработчик ожидает некоторой внутренней корреляции между двумя интерфейсами, фактически не создав эту корреляцию.

Вы можете сказать: «Но я знаю, что помещаю объект Example, компилятор тоже должен это знать!» но вы бы упустили тот момент, что если бы это был параметр метода, у вас не было бы возможности узнать, что отправляют вызывающие объекты вашего метода.

public void DoTheThing(Interface1 example)
{
    if (example instanceof Interface2) 
    {
        ((Interface2) example).someInterface2Method();
    }
}

Когда другие вызывающие объекты вызывают этот метод, компилятор останавливает их только в том случае, если переданный объект не реализует Interface1. Компилятор не собирается останавливать кого-либо от передачи объекта класса, который реализует Interface1, но не реализует Interface2.

Ваш пример не нарушает LSP, но, похоже, нарушает SRP. Если вы столкнулись с таким случаем, когда вам нужно привести объект к его второму интерфейсу, метод, содержащий такой код, можно считать занятым.

Реализация 2 (или более) интерфейсов в классе — это нормально. Решение о том, какой интерфейс использовать в качестве типа данных, полностью зависит от контекста кода, который будет его использовать.

Кастинг — это хорошо, особенно при смене контекста.

class Payment implements Expirable, Limited {
 /* ... */
}

class PaymentProcessor {
    // Using payment here because i'm working with payments.
    public void process(Payment payment) {
        boolean expired = expirationChecker.check(payment);
        boolean pastLimit = limitChecker.check(payment);

        if (!expired && !pastLimit) {
          acceptPayment(payment);
        }
    }
}

class ExpirationChecker {
    // This the `Expirable` world, so i'm  using Expirable here
    public boolean check(Expirable expirable) {
        // code
    }
}

class LimitChecker {
    // This class is about checking limits, thats why im using `Limited` here
    public boolean check(Limited limited) {
        // code
    }
}

Как правило, многие интерфейсы, специфичные для клиента, подходят и являются частью принципа разделения интерфейса ( «Я» в SOLID). Некоторые более конкретные моменты на техническом уровне уже упоминались в других ответах.

В частности, вы можете зайти слишком далеко с этой сегрегацией, создав такой класс, как

class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
    @Override String getFirstName() {...}
    @Override String getLastName() {...}
    @Override int getAge() {...}
    ...
}

Или, наоборот, что у вас слишком мощный класс реализации, как в

class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
    ...
}

Я думаю, что главное в принципе разделения интерфейсов заключается в том, что интерфейсы должны быть зависимыми от клиента. Они должны в основном «обобщать» функции, которые требуются определенному клиенту, для определенной задачи.

Скажем так: проблема в том, чтобы найти правильный баланс между крайностями, которые я обрисовал выше. Когда я пытаюсь понять интерфейсы и их отношения (взаимные и с точки зрения классов, которые их реализуют), я всегда стараюсь сделать шаг назад и намеренно наивно спросить себя: Кто собирается получить что и что он собирается с этим делать?

interface Combined extends Interface1, Interface2 { }

class Example {
    Interface1 getInterface1() { ... }
    Interface2 getInterface2() { ... }
}

interface DatabaseReader { String read(); }
interface DatabaseWriter { void write(String s); }

class Database {
    DatabaseConnection connection = create();
    DatabaseReader reader = createReader(connection);
    DatabaseReader writer = createWriter(connection);

    DatabaseReader getReader() { return reader; }
    DatabaseReader getWriter() { return writer; }
}

void create(DatabaseWriter writer) { ... }
void read  (DatabaseReader reader) { ... }
void update(DatabaseReader reader, DatabaseWriter writer) { ... }

create(database.getWriter());
read  (database.getReader());
update(database.getReader(), database.getWriter());