Есть ли какая-то истинная точка в интерфейсе Java?

Возможный дубликат:
Как фактически используются интерфейсы Java?

Я не говорю с точки зрения академического модного слова, но с точки зрения перспективного разработчика.

Итак, возьмем пример: -

    Class1 implements Interface 
 public String methodOne() {
  return "This is Class1.methodOne()";
 }

 public String methodTwo() {
  return "This is Class1.methodTwo()";
 }
    }
Class2:

    Class2 implements Interface 
 public String methodOne() {
  return "This is Class2.methodOne()";
 }

 public String methodTwo() {
  return "This is Class2.methodTwo()";
 }
    }

Использование интерфейса: -

 Client {
  Interface intface = new Class1();

  intface.methodOne();
  intface.methodTwo();

  Interface intface = new Class2();
  intface.methodOne();
  intface.methodTwo();
}

Но каковы преимущества только для написания: -

 Client {
Class1 clas1 = new Class1();

clas1.methodOne();
clas1.methodTwo();

Class2 clas2 = new Class2();
clas2.methodOne();
clas2.methodTwo();
 }

И вообще обходите интерфейс.

Интерфейсы просто кажутся дополнительным слоем кода для дополнительного слоя кода, или их больше для них, чем просто "Вот методы, к которым относится класс, к которому вы обращаетесь"?

Ответ 1

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

Ваш простой пример не оправдывает себя, но переименуйте свой интерфейс в нечто более полезное и конкретное, например. a Sorter, который может принимать список элементов и сортировать их. У вас может быть реализовано несколько различных алгоритмов сортировки, и вы можете захотеть изменить используемый алгоритм на основе контекста (например, QuickSort быстрее для больших наборов данных, но BubbleSort лучше подходит для небольших наборов данных и т.д.). Таким образом, вы не используете хотите связать код клиента с одним конкретным алгоритмом. Используя полиморфный тип Sorter (реализованный как интерфейс), вы можете передавать клиенту различные объекты конкретного сортировщика, не зная (и не заботясь) о том, какой алгоритм он фактически использует. И вы можете в любое время ввести лучший алгоритм сортировки или удалить тот, который оказался неэффективным, без того, чтобы клиенты ничего не замечали.

Такой подход невозможен без интерфейсов. Альтернативой будет вызов метода сортировки по выбору непосредственно из (возможно, дублированного) if-else или коммутационных блоков по всему месту с неизбежной возможностью введения ошибок при забытии обновить все места должным образом при добавлении/удалении алгоритма сортировки... не говоря уже о том, что вам нужно будет перекомпилировать весь клиентский код после каждого такого изменения: - (

Ответ 2

Предположим, вам нужна коллекция объектов с обоими методами "Method1" и "Method2". И вы не хотите программно проверять каждый экземпляр в коллекции для своего типа.
Коллекция объектов, которые реализует интерфейс, избавляет вас от этого.
Он вызывает полиморфизм, и он очень полезен.

Ответ 3

Другие люди в значительной степени затронули ваш вопрос, но одним словом: Да!

Язык Java фактически был задуман как довольно минимальный объектно-ориентированный язык, и интерфейсы были с самого начала. Существуют концепции описания отношений между классами, которые трудно или невозможно обойтись без каких-либо интерфейсов или некоторой высокопроизводительной идентификации типа времени исполнения. Все или почти все шаблоны, приведенные в знаменитой Design Patterns (здесь сама книга) полагаются на интерфейсы.

Ответ 4

(Не уверен, как я реагирую, не рассматривая его как ответ, но...)

Ничего себе, так много ответов так быстро, довольно впечатляющий форум - ура!:-D

Итак, было бы разумно сказать, что интерфейс существенно устанавливает "правила", для которых должны встречаться конкретные классы?

Например, если у меня были классы Class1 и Class2, оба из которых имеют метод getList(). Без реализации интерфейса Class1.getList() может вернуться, скажем, список строк и Class2.getList() может возвращать целые числа.

По сути, интерфейс устанавливает правила, которые мой класс должен иметь метод getList(), и этот метод должен возвращать List, поэтому, если оба реализуют интерфейс Lister с методом 'public String getList();' Я знаю, что и Class1, и Class2 getList() возвращает Список типов String.

Но конкретный Class1 может возвращать список отделов, тогда как Class2 - это список сотрудников, но я знаю, что оба они возвращают список строк.

Это, вероятно, станет более полезным, если бы у меня было, наверное, полдюжины или около того классов с полудюжинами методов, все из которых я хочу обеспечить соответствие .getList возвращает список типа String 'rule'.

Ответ 5

Я использую интерфейсы в основном для

моделирование множественного наследования
определение контракта на обслуживание и реализация службы
контракты обратного вызова одного метода

и потому что

для некоторых зависимостей инъекций требуется интерфейс для работы
mocking интерфейсы легче, чем насмешливые классы
многие системы AOP работают лучше с интерфейсами, чем классы

И это не действительно слой кода между сервисом и его клиентом, а скорее формальный контракт.

Ответ 6

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

Ответ 7

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

Примером преимущества интерфейсов, использующих ваш код, может быть:

public void useInterface(Interface obj) {
    obj.methodOne();
    obj.methodTwo();
}

и называя его как:

   useInterface(new Class1());
   useInterface(new Class2());

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

Ответ 8

Рассмотрим следующий метод, который получает список "intfaces", вам не нужно знать, обрабатываете ли вы clas1 или clas2, вы просто хотите обработать что-то, что является "intface". Вы можете добавить clas3 реализовать intface позже, и это будет работать...

  public void callMethods(List<intface> intfaces){
    for(Interface intface : intfaces) {
      intface.methodOne();
      intface.methodTwo();
    }
  }