Что такое интерфейсный фреймворк?

Question

Я изучал Effective Java и читал статические фабричные методы для создания объектов. Его глава 2, пункт 1. Там в плюсе нет. 3, писатель упомянул как

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

Я не мог понять, что такое интерфейсные фреймворки?

Answer 1

Может быть, немного перефразировала бы это:

основанная на интерфейсе структура - это структура, предоставляющая пользователю / клиенту lib доступ только к интерфейсам, в то же время фактически предоставляя классы, реализующие эти интерфейсы.

Преимущество этого подхода заключается в предоставлении разработчику полного контроля над реализацией и одновременном предоставлении клиенту стабильного API.

В последнее время я встречал пример, когда клиент получает XmlProcessor из метода API.,Внутри фреймворка есть три совершенно разные реализации этого процессора: DomXmlProcessor, SaxXmlProcessor и VtdXmlProcessor.Детали отдельных реализаций не имеют значения для клиента и могут быть переключены в любое время.

Answer 2

Основанные на интерфейсе платформы - это те платформы, которые разработаны с интерфейсом и его реализацией.

Фреймворк коллекции - хороший пример фреймворков на основе интерфейса.

Скрытие классов реализации таким способом может привести к очень компактному API

Вы просто создаете интерфейс

interface Animal{
 public void eat();//hiding the implementation
 public  Animal getAnimalInstance();//factory method
}

Ваш разработчик позаботится о реализации.

Ваш потребитель API будет напрямую использовать интерфейс, как мы делаем в коллекции

List<String> list = new ArrayList<String>();

См. Также

• когда лучше всего использовать интерфейс в Java

Answer 3

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

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

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

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

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

public interface Account {

  double getBalance();

  void credit(double amount);

  void withdraw(double amount);

  List<Operation> getOperations(Date startDate, Date endDate); 

}

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

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

Это красиво и красиво, но проблема остается. Как вы получаете свои аккаунты? То есть дисконтный счет в другом банке, безусловно, отличается от локального. Код отличается. И способ его создания тоже. Для удаленной учетной записи вам нужен, например, сетевой адрес для другого банковского сервера ... Другой может потребовать идентификатор базы данных.

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

Хорошей практикой является изоляция этой сложности в части вашего приложения. Это позволяет разделить сложные задачи на более мелкие и простые.

Я привел пример приложения учета, но на самом деле мы можем быть более общими. Создание объектов и извлечение уже созданных объектов является очень распространенной проблемой в любом программном обеспечении. Таким образом, у нас есть общие "хорошие способы" сделать это ремонтопригодным и чистым способом.

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

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

Answer 4

Фреймворки, которые предоставляют пользователям в основном интерфейсы (а не конкретные реализации)

Поскольку вы упомянули Bloch, я приведу пример со структурой коллекций.Вы можете видеть, что класс Collections имеет методы synchronizedX(..), unmodifiableX(..), singletonX(..).Это статические фабричные методы, и их много, но они только возвращают интерфейсы - List, Map, Set, SortedMap.За кулисами есть множество реализаций, о которых вам не нужно знать.

Другой пример (но без внимания статических фабрик) - это JDBC API.Там почти нет классов - Connection, Stetement, PreparedStatement, ResultSet и т. Д. - все интерфейсы.Это позволяет существовать множеству реализаций для разных баз данных без каких-либо различий для пользователя.(Представьте, что вам нужно использовать в своем коде классы, такие как MySQLStatement, OracleConnection и т. Д.)