[Spring] 스프링과 객체지향의 상관관계 - DI란 무엇일까?

레벨 2 수업 시간에 의존성 주입 관련 내용을 들으면서 조금 정리를 해보고 싶어서 간단하게 글을 작성해보고자 한다.

그동안 스프링은 객체지향적으로 작성하기 좋은 프레임워크라고 말은 들어봤지만, 정확하게 왜인지는 이해한 적이 없었다.

정리를 통해서 조금 더 머리에... 담아두고자 한다!

 

 

---

✔️ 객체지향적 설계과 디자인 패턴

우선, 객체지향 설계 원칙으로 많이들 언급하는 SOLID에 대해서 간단하게 생각해보자.

 

- SRP (단일 책임 원칙): 어떤 클래스를 변경하는 이유는 오직 하나뿐이어야 한다.

- OCP (개방 폐쇄 원칙): 자신의 확장에는 열려있고, 주변의 변화에는 닫혀있어야 한다.

- LSP (리스코프 치환 원칙): 서브 타입은 항상 자신의 기반 타입으로 교체할 수 있어야 한다.

- ISP (인터페이스 분리 원칙): 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺지 않아야 한다.

- DIP (의존 역전 원칙): 자주 변경되는 구체 클래스에 의존하지 않고, 추상화된 클래스에 의존해야 한다.

 

Spring에는 이러한 SOLID를 지키기 위해서 다양한 디자인 패턴을 사용하고 있다.

각 디자인 패턴에 대해서 다루면 너무 길어지기 때문에 간략하게만 설명하겠다.

 

1. 어댑터 패턴 : 호출당하는 쪽의 메서드를 호출하는 쪽의 코드에 대응하도록, 중간에 변환기를 통해 호출하는 패턴

어댑터 패턴은 서로 다른 인터페이스를 가진 두 객체를 연결해주는 패턴이다.

 

스프링에서는 다음과 같은 경우에 사용할 수 있다.

- JDBC 사용 시 DB 연동을 위해 DataSource 인터페이스의 구현체를 사용한다.

이때, 데이터베이스 시스템마다 dataSource 구현체가 다르기 때문에 스프링에서는 각각에 대해 DataSource 인터페이스에 맞도록 변환해주는 어댑터 패턴을 사용한다.

 

- JMS (Java Message Service) API 활용 시 JMS Adapter를 활용하여 둘 이상의 클라이언트 간 메시지를 보내기 위한 표준 Java 메시징 API를 제공한다.

 

2. 프록시 패턴 : 제어 흐름을 조정하기 위한 목적으로, 중간에 대리자를 두는 패턴

인터페이스를 사용하여, 실제 객체가 들어갈 자리에 대리자 객체를 투입하는 것이다.

클라이언트는 해당 요청을 받는 게 실제 객체인지, 대리자 객체인지는 알 수 없다.

 

이때, 대리자는 실제 서비스와 같은 이름을 가지는 메서드를 구현하며, 인터페이스를 활용한다.

실제 서비스에 대한 참조 변수는 Composition의 형태로 가지고 있으며,

대리자는 실제 서비스와 동일한 이름을 가지는 메서드를 호출하고, 그 값을 클라이언트에게 돌려준다, 

또한, 실제 서비스의 메서드 호출 전후에 별도의 로직을 수행해줄 수도 있다.

-> OCP와 DIP를 만족하게 된다.

 

스프링에서는 다음과 같은 경우에 사용할 수 있다.

- AOP : 메서드 실행 전-후의 로깅, 보안, 트랜잭션 처리의 부가 기능 사용 시 처리한다.

- 트랜잭션 관리: 프록시 객체는 트랜잭션을 시작 및 종료하는 등의 부가 기능을 처리한다.

- Lazy Loading: 빈 등록 시 Lazy하게 만든다면, 실제로 해당 빈이 사용되기 전까지 생성되지 않는다. 이때 프록시 객체를 통해 빈이 실제로 사용되는 시점 이전까지는 가지고 있다가, 사용 시 실제 객체를 생성하도록 하였다.

 

3. 데코레이터 패턴: 메서드 호출의 반환값에 변화를 주기 위해 중간에 장식자를 두는 패턴

프록시 패턴과 구현 방법은 동일하지만, 클라이언트에게 주는 반환값을 조작하여 반환하는 것이다.

 

4. 싱글턴 패턴: 클래스의 인스턴스를 딱 1개만 만들어서 사용하는 패턴

Connection pool, Thread Pool 같은 객체들은 여러 개의 인스턴스가 존재한다면 불필요한 자원을 사용하게 된다.

싱글턴 패턴을 만족하기 위해서는 new를 실행할 수 없도록 private 생성자가 필요하며, 단일 객체를 반환하기 위한 정적 메서드가 필요하다. 그리고, 해당 메서드는 단일 객체 (private static)를 반환하는 형태로 만들어낼 수 있다.

 

단일 객체는 공유 객체와 다름없기 때문에, 속성을 가져서는 안 된다. (읽기 전용 속성은 괜찮다)

: 이는 싱글턴 빈이 가져야 하는 제약 조건이기도 하다.

 

5. 템플릿 메서드 패턴: 상위 클래스의 템플릿 메서드에서 하위 클래스가 오버라이딩한 메서드를 호출하는 패턴

상위 클래스를 추상 클래스를 선언해두고, 해당 클래스의 구현체들이 공동으로 할 행위에 대해 템플릿 메서드를 정의한다.

해당 템플릿 메서드는 추상 메서드를 호출하도록 만들어서 해당 추상 메서드를 구현한 하위 클래스가 (반드시 오버라이딩해야 함) 개별 특성에 맞는 동작을 하도록 해서, 공통적인 동작 + 개별적인 동작을 하도록 만드는 것이다. (DIP 만족)

 

6. 팩터리 메서드 패턴: 오버라이딩된 메서드가 객체를 반환하는 패턴

스프링에서는 빈 생성 시 팩터리 메서드 패턴을 사용한다.

BeanFactory와 이를 상속받은 ApplicationContext를 제공하는데, 여기서 객체 생성 및 초기화는 빈 팩터리가 호출하게 된다.

 

7. 전략 패턴: 클라이언트가 전략을 생성해, 전략을 실행할 컨텍스트에 주입하는 패턴

전략 패턴에서는 전략 메서드를 가진 객체와, 전략 객체를 사용하는 컨텍스트, 그리고 전략 객체를 생성하여 컨텍스트에 주입하는 클라이언트로 나누어져 있으며, 전략에 따라 클라이언트가 주입하는대로 결과가 달라지는 방식이다.

 

8. 템플릿 콜백 패턴: 전략을 익명 내부 클래스로 구현한 전략 패턴

DI에서 사용하는 기법 중 하나로, 전략 패턴과 동일하지만 전략을 익명 내부 클래스로 정의해서 사용하는 패턴이다.

 

스프링에서는 위와 같은 디자인 패턴 + SOLID 적용을 통해 객체지향적으로 설계할 수 있도록 도와주는 것이다.

 

---

✔️ IoC와 DI

이에 대해서 정리하기 위해서는, 애플리케이션의 '의존도' 에 대해서 먼저 생각해야 한다.

 

의존성을 맺는다는 것은 무엇을 말하는 것일까?

하나의 클래스가 다른 클래스를 사용하거나, 생성하거나, 혹은 호출한다면 의존성을 맺는다고 볼 수 있다.

여기서 클래스의 생성과 사용의 관점에 주목해보자.

 

예시를 위해 간단한 클래스를 작성하였다.

public interface Animal {
    String sayHi();
}

동물을 나타내는 인터페이스와 인사하는 행위를 정의한 메서드가 존재한다.

public class Cat implements Animal {
    @Override
    public String sayHi() {
        return "냥냥";
    }
}

public class Dog implements Animal {
    @Override
    public String sayHi() {
        return "멍멍";
    }
}

그리고, 그에 대한 구현체로 고양이와 강아지 객체가 있다.

 

public class Zoo {
    private final Animal animal;

    public Zoo() {
        this.animal = new Cat();
    }

    public void sayHello() {
        System.out.println(animal.sayHi());
    }
}

그 다음, 동물원 객체에서 동물을 생성해서 인사를 하도록 시켰다.

위의 클래스를 보면, Zoo 클래스는 Cat 클래스의 생성 및 사용까지 담당하고 있다.

이런 식으로 사용과 생성을 하나의 클래스에 한 번에 한다면 무슨 일이 있을까?

 

1. 결합도가 강해 서로의 변화에 민감해진다 (OCP 위반)

만약 Cat의 sayHi라는 메서드가 없어진다면?

혹은, sayHi라는 메서드의 반환형이 String 대신 void가 된다면 어떻게 될까?

= Cat의 변화가 Zoo까지 영향을 미치게 되면서 변경에 열려있게 된다. (+ 유지-보수 관점에서도 좋지 않다)

좋은 객체지향 설계의 5가지 원칙 - SOLID에서 OCP를 위반하는 형태가 되는 것이다.

 

2. SRP를 위반하고 있다

Zoo는 Cat에 대해 생성하는 책임 및 사용하는 책임까지, 총 2가지의 책임을 가지고 있게 된다.

좋은 객체지향 설계의 5가지 원칙 - SOLID에서 SRP를 위반하는 형태가 되는 것이다.

 

그렇다면, 위와 같은 코드를 어떻게 분리할 수 있을까?

 

---

 

🌱 생성자를 통해 의존성을 주입해주기

Zoo 클래스에서 Animal에 대해서 생성하지 않고, 생성에 대한 책임을 외부로 분리하는 것이다.

public class Zoo {
    private final Animal animal;

    public Zoo(final Animal animal) {
        this.animal = animal;
    }

    public void sayHello() {
        System.out.println(animal.sayHi());
    }
}

외부에서 Animal에 대한 객체를 생성하도록, 주입하는 형식으로 변경하는 것이다.

public class Driver {
    public static void main(String[] args) {
        Animal cat = new Cat();
        Zoo zoo = new Zoo(cat);

        System.out.println(zoo.sayHi());
    }
}

의존성 주입을 적용하면, Zoo는 그냥 Animal 인터페이스를 구현한 객체가 들어오기만 하면 정상적으로 작동한다.

만약 Cat이 제거되고, Duck이 들어오더라도 Zoo에는 아무런 영향을 끼치지 않는다. 

이렇게 외부의 변화는 영향을 받지 않아 변경에는 닫혀있지만, 새로운 객체가 추가되더라도 상관 없어서 확장에 열려있게 된다.

그저, Animal에서 구현한 객체가 들어오기만 하면 되는 것이다.

 

디자인 패턴의 관점에서 보았을 때도 전략 패턴을 사용했다고 볼 수 있다.

여기서 전략은 Animal을 구현한 Cat, Dog이라고 할 수 있고, 컨텍스트는 Cat의 sayHi가 되며, 클라이언트는 Driver의 main 메서드가 된다.

 

---

🌱 setter를 통해 의존성 주입하기

동물원에 존재하는 동물을 교체(ㅠㅠ)한다는 느낌으로, 수정자를 통해서 의존성 주입을 해줄 수 있다.

public class Zoo {
    private Animal animal;

    public void setAnimal(final Animal animal) {
        this.animal = animal;
    }

    public void sayHello() {
        System.out.println(animal.sayHi());
    }
}

public class Driver {
    public static void main(String[] args) {
        Animal cat = new Cat();

        Zoo zoo = new Zoo();
        zoo.setAnimal(cat);

        zoo.sayHello();
    }
}

마찬가지로 잘 동작하는 것을 볼 수 있다.

---

 

🌱 Spring - @Autowired 활용하기

이제 우리는 이러한 주입을 완전히 외부에게 넘기고 싶다. 스프링의 IoC - 제어의 역전을 사용할 수 있다.

@Component
public class Cat implements Animal {
    @Override
    public String sayHi() {
        return "냥냥";
    }
}

@Component
@Primary
public class Dog implements Animal {
    @Override
    public String sayHi() {
        return "멍멍";
    }
}

@Autowired는 기본적으로 타입으로 조회하기 때문에, 동일한 타입의 경우 @Qualifier로 구분할 수 있는 조건을 주거나, @Primary로 우선순위를 지정해야 한다. 여기서는 Dog에 Primary를 걸었다.

 

@Component
public class Zoo {
    private final Animal animal;

    @Autowired
    public Zoo(final Animal animal) {
        this.animal = animal;
    }

    public String sayHello() {
        return animal.sayHi();
    }
}

이렇게 되면 Zoo에 대해서 선언할 때 Animal 타입에 대해서 자동으로 Dog 타입이 주입될 것이다.

테스트 코드를 돌려보자.

@SpringBootTest
class ZooTest {

    @Autowired
    private Zoo zoo;

    @Test
    void test() {
        String expected = zoo.sayHello();
        assertThat(expected)
                .isEqualTo("멍멍");
    }
}

테스트 결과, 성공으로 나온 것을 볼 수 있다.

이런 식으로 객체의 생성 및 주입 자체를 스프링에게 책임을 넘겨서 개발자가 신경쓰지 않도록 하는 것이 스프링이 제공하는 기능이다!

 

또한, 의존 관계의 순환 참조 등을 서버 구동 시점에 막아줄 수 있는 것도 하나의 기술적 장점이기도 하다 :D

마지막으로 다양한 의존성 주입 방식에 대해서 특징을 정리하며 글을 마무리하고자 한다.

 

1. 생성자 주입
- 호출 시점에 1회 호출되는 것이 보장되며, 생성자가 한 개라면 @Autowired 생략 가능

2. 수정자 주입 (setter)
- 주입 받는 객체가 변경될 가능성이 있는 경우 사용 

3. 필드 주입
- 외부에서 접근이 불가능하기 때문에 테스트하기 쉽지 않다. (DI 프레임워크가 반드시 존재해야 한다)

 

🌱 생성자 주입의 장점

1. 객체의 불변성 (final로 선언 - 객체 생성 시에 초기화되기 때문에 변경 가능성을 없앤다)
+ 롬복을 사용하면 @RequiredArgsConsturctor를 통해 더 간결한 코드 작성 가능
2. 테스트 코드 작성이 용이함 (생성자를 통해 다른 mock 객체 주입이 용이함)

사실 불변성이 가장 큰 것 같다!

2.6 이하 버전에서는 필드 주입과 다르게 생성자 주입에서는 순환 참조가 서버 구동 시 발생했었는데, 2.6부터는 기본적으로 순환 참조를 막았기 때문에 오직 생성자 주입만의 장점이라고 보기는 어려워졌다. (기존에는 필드 주입에서는 호출이 되어야만 잡을 수 있었음)