В чем разница между обычным программированием и программированием с использованием Spring?

Question

Я понимаю как можно использовать Spring, но я до сих пор не могу понять то, о чём везде так пишут: "Мы разрываем жёсткую связку между классами" и т.д., и т.п.

Но ведь мы и так жёстко всё прописываем либо в аннотациях, либо в *.xml, да и к тому же в Main, когда пишем что-то вида:

Cat cat = context.getBean(Cat.class);
Dog dog = (Dog) context.getBean("dog");
Parrot parrot = context.getBean("parrot-kesha", Parrot.class);

Мы ведь и так тут всё жёстко прописали.

Также, Spring использует интерфейсы для ухода от жёсткой зависимости между классами. Тогда что мне мешает без Spring сделать интерфейс IAnimals и в нём метод void voice();,

а потом, просто сделать:

class Cat implements IAnimals {
    public void voice() {
        System.out.print("myau");
}}
class Dog implements IAnimals {
    public void voice() {
        System.out.print("gav");
}}
class Parrot implements IAnimals {
    public void voice() {
        System.out.print("kesha");
}}

Вот эту разницу между обычным программированием и программированием с использованием Spring я не могу понять.

Answer 1

Вот вам реальный пример. Отправка sms на тестовом сервере и на рабочем. В коде который отправляет sms работаем с интерфейсом, а реализацию spring подставляет в зависимости от сервера. Если понадобится отправлять sms сообщение через другой сервис просто добавим новую реализацию, и не будем переписывать весь код, откуда отправляется sms.

interface SmsService {
    void send(String to, String message);
}

@Service
@Profile("development")
class DevelopmentSmsService implements SmsService  {
    public void send(String to, String message) {
        // печать сообщения в лог
    }
}

@Service
@Profile("production")
class ProductionSmsService implements SmsService  {
    public void send(String to, String message) {
        // отправка сообщения через API нужного сервиса
    }
}

@Service
class AnotherService {

    @Autowired
    SmsService smsService;

    public test() {
        // что-то делаем
        // отправляем sms через интерфейс, не заботясь о подробностях
        smsService.send(to, message);
    }
}

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

Answer 2

Жесткая или не жесткая определяется тем, как вы будете использовать IAnimals. Для чего вы создали интерфейс? Для того чтобы иметь классы, которые его имплементируют. Если у вас несколько имплементаций, а вам нужна конкретная имплементация, то вы используете паттерн метода фактора или абстрактного фактора для создания экземпляра класса, который имплементирует этот интерфейс.

Таким образом вы можете внедрять нежесткую связь в другие классы без использования Spring.

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

Более того, поскольку Spring берет на себя проблему создания бинов, то он еще и занимается менежментом. Что дает возможность интегрироваться в другие фреймворки.

Answer 3

Основная фича Spring это его DI контейнер. Мы можем внедрять зависимости в бины, не задавая жестко тип. Вот Вы привели пример с интерфейсом Animal. Давайте разовьем немного тему. Допустим мы имеем вет. клинику и можем заставлять "говорить" любое животное. При этом нам абсолютно не важно какое это будет животное. Таким образом мы можем написать логику извлечения звука из животных один раз, а самих животных придумывать по ходу пьесы. И не придется править код вет. клиники, а лишь добавлять новых и новых Animal.

@Component
public class Clinic {

    private final List<Animal> animals;

    @Autowired //ЕМНИП, в крайних версиях, даже этого делать уже не нужно
    public Clinic(List<Animal> animals) {
        this.animals = animal;
    }

    public void doVoice() {
        for (Animal animal : animals) {
            animal.voice();
        }
    }
}

public interface Animal {
    void voice();   
}

@Component
public Cat implements Animal {

    @Override
    public void voice() {
        System.out.print("myau");
    }
}

@Component
public Dog implements Animal {

    @Override
    public void voice() {
        System.out.print("gav");
    }
}

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

Spring это уже не просто очередной фреймворк, это, можно сказать, промышленный стандарт.

Советую к прочтению "Spring In Action" Крэйга Уолша, очень доступно товарищ объясняет.