Java Interface-Implementation Pair [closed]

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

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

Статические реализации имеют две проблемы:

• вы не можете найти их с помощью какого-либо статического анализа кода, например, перечисления всех разработчиков, потому что статический метод не реализует интерфейс, поэтому вы вынуждены упомянуть значение по умолчанию реализации в javadoc

• иногда необходимо иметь какое-то состояние в разработчике, что на самом деле не может быть выполнено в рамках статического метода

. Поэтому я предпочитаю использовать конкретный класс, который допускает наследование (если вы не ограничен единичным наследованием) и композицией, и вызовет результирующий класс * Peer, поскольку он обычно будет использоваться вместе с основным классом, реализующим интерфейс. Одноранговый узел будет реализовывать интерфейс, а также может иметь ссылку на основной объект в случае, если ему нужно запускать события от имени основного класса.

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

Для функциональности с отслеживанием состояния я бы предпочел композицию вместо наследования. С помощью композиции и использования делегатов / адаптеров вы можете комбинировать функциональность по умолчанию из многих источников.

например.

public interface StuffDoer{
    void doStuff();
    void doOtherStuff();
}

public class MyStuffDoer implements StuffDoer{
    private final StuffDoer mixin;
    public  MyStuffDoer(StuffDoer mixin){
        this.mixin = mixin;
    }
    public void doStuff(){
        mixin.doStuff();
    }
    public void doOtherStuff(){
        mixin.doOtherStuff();
    }

}

public class MyStuffDoer2 implements StuffDoer{
    private final StuffDoer mixin1, mixin2;
    public  MyStuffDoer(StuffDoer mixin1, StuffDoer mixin2){
        this.mixin1 = mixin1;
        this.mixin2 = mixin2;
    }
    public void doStuff(){
        mixin1.doStuff();
    }
    public void doOtherStuff(){
        mixin2.doOtherStuff();
    }

}

Для простых случаев наследование тоже нормально, но на самом деле оно не очень гибкое.

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

public interface A{
    void doStuff();
}

public interface B{
    void doOtherStuff();
}

public class MyStuffDoer implements A, B{
    private final A mixin1;
    private final B mixin2;
    public  MyStuffDoer(A mixin1, B mixin2){
        this.mixin1 = mixin1;
        this.mixin2 = mixin2;
    }
    public void doStuff(){
        mixin1.doStuff();
    }
    public void doOtherStuff(){
        mixin2.doOtherStuff();
    }
}

Вы не можете сделать это с абстрактными классами. Я использовал этот подход к композиции в нескольких проектах, и он отлично сработал.

Я более или менее следую шаблону, который изначально усвоил у Swing. У меня есть интерфейс, и я создаю класс «Базовый» или «Адаптер». Для меня адаптер часто имеет бездействующие реализации для всех методов интерфейса, чтобы позволить разработчику писать только те методы, которые им нужны, игнорируя другие. Базовым будет абстрактный класс, который предоставляет удобные реализации для некоторых методов интерфейса - будем надеяться, что это «наиболее вероятная» реализация.

Например, у меня есть интерфейс SearchFilter, который, помимо прочего, имеет метод apply (Collection ) . Этот метод почти всегда будет перебирать коллекцию и вызывать метод интерфейса boolean include (T item) , чтобы решить, сохранить или отфильтровать элемент. My SearchFilterBase предоставляет это в качестве реализации для apply (), а разработчик должен только написать свою логику include ().

Разработчики, конечно, могут просто реализовать весь интерфейс сами, а не унаследовать его от Base, что является преимуществом по сравнению с изменением интерфейса на абстрактный класс, что вынуждает их использовать свое единственное наследование (это проблема с java.util.Observable)

В ответ на комментарий N8g - Вы можете создать подкласс базы или адаптера, но не требуемый подкласс - вы можете реализовать интерфейс самостоятельно с нуля.База или адаптер предоставляется для удобства, реализуя безоперационные методы, поэтому вам не нужно это делать, или реализуя удобные общие функции в абстрактном базовом классе (например, мой класс SearchFilterBase ). Преимущество этого по сравнению с превращением интерфейса в абстрактный класс состоит в том, что вы не вызываете наследование от абстрактного класса.

В большинстве случаев я использую что-то вроде этого:

public interface Something {
  public void doSomething();

  public static class Static {
    public static void doSomething(Something self) {
      // default implementation of doSomething()
      // the name of the method is often the same
      // the arguments might differ, so state can be passed
    }
  }

  public static abstract class Abstract implements Something {
    // the default abstract implementation
  }

  public static class Default extends Abstract {
    // the default implementation
    public void doSomething() {
      Static.doSomething(this);
    }
  }

  public static interface Builder extends Provider<Something> {
    // initializes the object
  }
}

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

Кроме того, вы можете поместить служебный класс ( Static ) в отдельный файл, если методы касаются не только интерфейса.

Кстати, проблема с декораторами в том, что они скрывают другие реализованные интерфейсы. Другими словами, если у вас есть декоратор something, следующее значение false new SomethingDecorator (new ArrayList