Почему все методы интерфейса должны быть реализованы в классе, реализующем его в java

Ответ 1

Идея интерфейса в Java очень похожа на контракт (и, возможно, в ретроспективе это должно было быть название концепции)

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

По моему опыту это средство - одна из вещей, которая позволяет строить соборы в Java.

Ответ 2

То, что вы критикуете, - это достижение цели. Если вы не хотите реализовывать интерфейс, не объявляйте свой класс, реализующий его.

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

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

Ответ 3

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

Существует два общих способа устранения необходимости не выполнять некоторые функции:

• Добавление метода тестера и реализации, которая выбрасывает UnsupportedOperationException и
• Разделение интерфейса по мере необходимости на части, чтобы можно было реализовать весь метод части.

Вот пример первого подхода:

public interface WithOptionalMehtods {
    void Optional1();
    void Optional2();
    boolean implementsOptional1();
    boolean implementsOptional2();
}

public class Impl implements WithOptionalMehtods {
    public void Optional1() {
        System.out.println("Optional1");
    }
    public void Optional2() {
        throw new UnsupportedOperationException();
    }
    public boolean implementsOptional1() {
        return true;
    }
    public boolean implementsOptional2() {
        return false;
    }
}

Вот пример второго подхода:

public interface Part1 {
    void Optional1();
}
public interface Part2 {
    void Optional2();
}
public Impl implements Part1 {
    public void Optional1() {
        System.out.println("Optional1");
    }
}

Ответ 4

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

Да, ты прав. Вот почему лучше всего использовать в кодировании, чтобы следовать принципу Interface Segregation Principle, который рекомендует не принуждать клиентов выполнять интерфейсы, которые они не используют. Таким образом, у вас никогда не должно быть одного "жирного" интерфейса со многими методами, кроме многих небольших методов группировки интерфейсов, каждая группа обслуживает определенное поведение или подмодуль.
Таким образом, клиенты интерфейса реализуют только необходимые методы, не будучи вынуждены внедрять методы, которые им не нужны.

Ответ 5

Это может зависеть от Принцип замены Лискова

Таким образом, наличие A implements B означает, что вы можете использовать A, когда требуется B и, чтобы заставить его работать без проблем, A должен иметь по крайней мере те же методы B.

Пожалуйста, имейте в виду, что мой не является "правильным" ответом, поскольку он не основан на официальных источниках!

Ответ 6

При реализации интерфейса нам может не понадобиться определять весь метод, объявленный в интерфейсе. Мы можем определить некоторые методы, которые нам не нужны. Ничего внутри тела.