пружина и интерфейсы

легко генерировать прокси от интерфейсов.

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

Большинство ответов здесь является некоторой формой "Вас, может легко выгрузить реализации", но что я думаю, что им не удается ответить, почему? часть. К этому я думаю, что ответ является почти окончательно тестируемостью. Независимо от того, используете ли Вы Spring, или любая другая платформа МОК, с помощью Внедрения зависимости делает код легче протестировать. В случае говорят, что писатель, а не PrinterWriter, можно Дразнить интерфейс Writer в Модульном тесте и удостовериться, что код называет его способом, к которому Вы ожидаете его. Если Вы зависите непосредственно от реализации класса, Ваша единственная опция состоит в том, чтобы идти к принтеру и проверить его, который не очень автоматизирован. Кроме того, если Вы зависите от результата вызова к классу, не быть способным Дразнить его может предотвратить Вас от способности достигнуть всех путей выполнения кода в Вашем тесте, таким образом уменьшая их качество (потенциально) Проще говоря, необходимо разъединить создание Графа объектов от прикладной логики. Выполнение так делает Ваш код легче протестировать.

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

Вот несколько примеров:

1. Говорят, что Вы пишете класс, который должен читать из ресурса (например, файл), на который можно сослаться несколькими способами (например, путем к классу, абсолютным путем к файлу, как URL и т.д.). Вы хотели бы определить org.springframework.core.io.Resource (интерфейсное) свойство на Вашем классе. Тогда в Вашем конфигурационном файле Spring, Вы просто выбираете класс фактической реализации (например, org.springframework.core.io.ClassPathResource, org.springframework.core.io.FileSystemResource, org.springframework.core.io.UrlResource и т.д.). Spring в основном функционирует как чрезвычайно универсальную фабрику.

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

Это примеры, с которыми у меня лично есть опыт. Я уверен, что существует намного больше там.

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

при использовании, например, Быть в спящем режиме классов поддержки можно определить интерфейс для ДАО, затем реализовать его отдельно; преимущество наличия интерфейса состоит в том, что Вы будете в состоянии настроить его с помощью перехватчиков Spring, которые позволят Вам упрощать свой код; Вы не должны будете писать cathing HibernateExceptions кода и закрывание сеанса в наконец сегмент, и Вы не должны будете определять транзакции программно также, Вы просто настраиваете все это декларативно с Spring.

, Когда Вы пишете быстрые и грязные приложения, можно реализовать некоторый простой ДАО с помощью JDBC или некоторой простой платформы, которую Вы не закончите тем, что использовали в окончательной версии; Вы будете в состоянии легко выключить те компоненты, если они реализуют некоторые единые интерфейсы.

Принцип Инверсии Зависимости объясняет это хорошо. В частности, рисунок 4.

A. Модули высокого уровня не должны зависеть от низкоуровневых модулей. Оба должны зависеть от абстракций.

B. Абстракция не должна зависеть от деталей. Детали должны зависеть от абстракций.

Перевод примеров из ссылки выше в Java:

public class Copy {
    private Keyboard keyboard = new Keyboard(); // concrete dependency
    private Printer printer = new Printer();    // concrete dependency
    public void copy() {
        for (int c = keyboard.read(); c != KeyBoard.EOF) {
            printer.print(c);
        }
    }
}

Теперь с инверсией зависимости:

public class Copy {
     private Reader reader; // any dependency satisfying the reader interface will work
     private Writer writer; // any dependency satisfying the writer interface will work
     public void copy() {
        for (int c = reader.read(); c != Reader.EOF) {
            writer.write(c);
        }
     }
     public Copy(Reader reader, Writer writer) {
         this.reader = reader;
         this.writer = writer;
     }
}

Теперь Copy поддержки больше, чем просто копирование с клавиатуры на принтер.

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

И теперь с Spring:

<bean id="copy" class="Copy">
    <constructor-arg ref="reader" />
    <constructor-arg ref="writer" />
</bean>

<bean id="reader" class="KeyboardReader" />
<bean id="writer" class="PrinterWriter" />

или возможно:

<bean id="reader" class="RemoteDeviceReader" />
<bean id="writer" class="DatabaseWriter" />