[스프링1] 객체 지향 설계와 스프링, DI

🔍 스프링의 탄생 배경

2000년대 초반, 자바 개발자들은 EJB라는 서버 컴포넌트 모델을 사용했다.

유연함을 찾아보기 힘든 정형화된 애플리케이션으로, 자바 개발자들은 객체 지향 언어를 사용함에도 객체 지향적인 서버 개발을 이어나가는 것이 쉽지 않았고 심지어 느렸다.

그러던 무렵, 이에 불만을 가진 몇 개발자의 노력으로 드디어 '스프링'이 세상에 나온다. 현재는 스프링과 함께 JPA, 하이버네이트가 많이 사용되고 있다.

🔍 스프링 개발을 돕는 다양한 도구

• 스프링 데이터 : 각종 DB의 CRUD를 돕는 기술(예: 스프링 데이터 JPA)
• 스프링 세션 : 세션 기능을 편리하게 돕는 기술
• 스프링 시큐리티 : 보안 기능 편의 기술
• 스프링 Rest Docs : API 문서화 및 테스트 간편화 기술
• 스프링 배치 : 배치 처리에 특화된 기술
  • 배치 처리 : 1000만 건의 데이터를 변경해야 할 때 n개 단위로 쪼개서 작업하는 것
• 스프링 클라우드 : 클라우드 기능을 편리하게 돕는 기술

🔍 스프링 부트

스프링 부트란, 스프링을 편하게 사용할 수 있도록 여러 가지 초기 세팅과 관리를 도와주는 도구이다.

starter 종속성을 제공하거나 서드파티 라이브러리 중 원하는 것을 고르면 이것들이 포함된 새 프로젝트를 생성해준다.

게다가 Tomcat 같은 내장 웹 서버도 가지고 있어 별도로 웹 서버에 올릴 필요가 없다.

🔍 객체 지향 프로그래밍

📌 목표

프로그래밍을 명령어의 나열이라 생각하지 않고 ‘객체’의 묶음이라고 생각하고 객체들의 독립적이고, 때로는 종속적인 상호작용을 통해 프로그램을 구성하는 것을 목표로 한다.

 

📌 다형성

각 객체들은 유연하고 변경이 쉽도록 만드는 것이 장점이며, 이러한 이유로 대규모 프로젝트에 많이 활용된다.

객체 지향 언어의 가장 큰 특장점인 '다형성'도 빼놓을 수 없다.

객체를 설계할 때 부모격인 인터페이스를 먼저 설계하고, 인터페이스의 특성을 갖고 있는 구현 객체(클래스)를 통해 비슷하지만 다른 여러 가지 형질의 객체를 생성할 수 있다는 점이 특징이다.

🔍 SOLID 원칙

1. SRP 단일 책임 원칙(Single responsibility principle)
   • 한 클래스는 하나의 책임만 가져야 한다.
   • 변경할 때 많은 부분을 변경하지 않는지 여부가 중요하다. 그렇다고 모든 기능을 다 쪼개면 곤란하다. 그렇다고 하나의 클래스에 너무 많은 책임이 들어가서도 안 된다. 적절한 양을 유지하는 것이 중요하다.
2. OCP 개방-폐쇄 원칙(Open/closed principle)
   • 소프트웨어의 요소는 확장에는 열려 있으나 변경에는 닫혀야 한다.
   • 다형성
     • 인터페이스를 구현하는 ‘새로운 클래스’를 통해 새로운 기능을 확장한다.
     • 기존 클래스는 건드리지 않는다.
3. LSP 리스코프 치환 원칙
   • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
   • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.
4. ISP 인터페이스 지원 원칙
   • 기능에 맞게 인터페이스도 적당히 쪼개야 한다.
5. DIP 의존관계 역전 원칙
   
   • 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다.
   • 만약에 구현 클래스까지 의존하고 있다면, 구현 클래스를 변경했을 때 그 부분도 함께 변경해주어야 하므로 DIP 위반이다.

🔍 SOLID 원칙을 지키는 스프링 코드란?

강의에서는 다형성을 활용한 코드를 소개한다. 설명을 위해 강의 자료를 첨부한다.

 

여기에서 주목해야 할 부분은 회원 저장소와 할인 정책이다. '회원 저장소 역할'과 '할인 정책 역할(DiscountPolicy)'은 인터페이스로, 하위의 저장소와 정책은 구현 클래스로 만들어져 있다.

이때 저장소와 정책을 원할 때마다 변경하고, 동시에 적은 수정으로 정말 필요한 곳에만 변경점을 주는 것이 목표다.

우리가 지금까지 작성했던 코드의 모습은 아래와 같다.

 

private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

이 코드 자체가 문제가 되지는 않지만, 이 코드가 클라이언트단에서 실행된다면 문제가 발생한다.(OCP 위반)

우리는 서버에서의 변경점을 클라이언트 모르게 적용하는 걸 목표로 했는데, 이 코드가 클라이언트에 있는 거다.

클라이언트 입장에서는 할인 정책이 어떤 것이든 상관없이 '클라이언트가 원하는 할인이 적용되면 되는데', 이렇게 되면 클라이언트가 직접 정액 할인 정책을 사용할 건지, 정률 할인 정책을 사용할 건지 정하는 꼴이 되니 말이다.

 

'난 정률 할인 정액 할인 그게 뭔지 모르겠고 10% 할인해달라고~'

 

문제가 하나 더 있다. 이게 더 확실한 문제다.

인터페이스 DiscountPolicy와 이를 구현한 구현 클래스 FixDiscountPolicy가 존재한다는 점이다. 아까 봤던 SOLID 원칙 중 DIP를 위반한 것이다. 그럼 결국 아래와 같은 코드를 구현하라는 건가?

private DiscountPolicy discountPolicy;

비슷하다. 근데, 그럼 어떤 할인 정책을 사용하는지는 언제 알게 되지?

생성자를 통해 의존성을 주입하는 작업이 이때 일어난다. 이를 DI(Dependency Injection)이라고 한다.

 

그리고 이러한 작업을 클라이언트에서 독립시키기 위해 AppConfig 파일을 만들어 애플리케이션의 전체 동작 방식을 구성하도록 한다. 이를 기반으로

 

1) 생성자를 통한 의존성 주입

    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }

2) AppConfig 파일 내에서 클라이언트 실행하며 원하는 클래스를 생성자 파라미터로 삽입

public OrderService orderService() {
        return new OrderServiceImpl(new FixDiscountPolicy());
}

3) 실행 및 테스트 시에 AppConfig를 선언하여 그 안의 orderService 호출

AppConfig appConfig = new AppConfig();
OrderService orderService = appConfig.orderService();

이렇게 실행해주면 OCP, DIP 위반 요소가 제거된다.

❓ 퀴즈

1. 스프링 부트란?
2. SOLID 원칙 5가지는 무엇인가?
3. 객체 지향 프로그래밍의 장점 중 상속을 통해 하나의 객체가 여러 종류가 될 수 있다는 특징은?
4. 스프링 도구 중 스프링 데이터의 예시는?
5. DIP 의존 관계 역전 원칙을 위반하는 예시를 말해보자.

 

해당 포스트는 스프링 핵심 원리 - 기본편 강의 내용을 참고하였습니다.

 

---

Spring 1

Editor : PORO