[Spring] 순수 자바 코드를 이용해 Service 구축하기 - 3

 

정리

---

 

지금까지 순수 자바코드를 이용하여 간단한 회원 가입과 할인 , 그리고 주문을 하는 서비스를 만들어보았다.

처음에는 각 '클라이언트 객체'(ServiceImpl) 에서 직접 구현객체를 생성하는 문제가 있었다.

이는 OCP , DIP 위반이므로 이를 해결하기 위해 AppConfig 를 만들어 모든 설정정보(구현객체)를 만들고 생성자를

통해 주입하였다.

이제 클라이언트 객체는 자신의 역할을 수행하는 것에만 집중 할 수 있고 , 설정 정보는 AppConfig 에서 주입해줄 수

있다. 

이렇듯 구현과 역할을 분리하는 것은 자바의 '다형성' 을 만족시키는 과정이다.

 

SOLID 5원칙

---

좋은 객체지향 설계의 5원칙 : SOLID

 

1. SRP : 단일책임원칙(Single Responsibility Principle)

-> 한 클래스는 하나의 책임만 가져야한다. 즉 변경 시 파급효과가 적으면 적을수록 단일 책임 원칙을 잘 지키는 것이다.

 

2. OCP: 개방-폐쇄 원칙 (Open/closed principle) 

-> 확장에는 열려있으나 변경에는 닫혀있어야 한다. 예를 들면 ,

DiscountPolicy discountPolicy = new FixDiscountPolicy();

DiscountPolicy discountPolicy = new RateDiscountPolicy();

이는 코드의 변경이 일어난다. 이를 해결하기 위해서 객체의 생성자만 만들고 AppConfig를 만들었었다.

 

3. LSP: 리스코프 치환 원칙 (Liskov substitution principle)

-> 프로그램의 객체는 정확성을 깨뜨리지 않으며 하위 인스턴스로도 바꿀수 있어야 한다.

 

4. ISP: 인터페이스 분리 원칙 (Interface segregation principle)

-> 클라이언트를 위한 인터페이스는 하나로 구현하는 것보다 , 여러 개를 구현해서 상속하는게 더 낫다.

 

5. DIP: 의존관계 역전 원칙 (Dependency inversion principle)

-> 추상화에 의존해야지 , 구체화에 의존하면 안된다. 2번과 연결되는 의미로 , 구현 클래스에 의존하면 안된다.

 

 

제어의 역전(IoC)

---

OrderServiceImpl (클라이언트 객체) 에서는 직접 제어를 담당하였다.

-> 직접 구현 객체를 생성해서 어떤 객체들을 받을지 정했다. 이렇듯 프로그램의 제어 흐름을 직접 제어했었지만

AppConfig 를 통해 외부에서 직접 제어를 담당한다. 이제 클라이언트 객체들은 AppConfig 를 제외한 본인의 코드만 보았을 때 , 어떤 객체를 주입받을지 전혀 알 방법이 없다. 이를 제어의 역전(Inversion of Control) 이라고 한다.

 

의존관계 주입

---

 

우리가 만든 코드들은 동적인 객체 인스턴스 관계이다. 프로그램을 실행하기 전까지는 어떤 구현 객체를 상속받을지 클라이언트 입장에서는 모르나 , 실행하게 되면 외부(AppConfig)에서 객체를 주입받고 명령을 시행한다.

이처럼 애플리케이션 실행 시점(런타임)에 외부에서 구현 객체를 주입하는 것을 '의존관계 주입' 이라고 한다.

이러한 'AppConfig' 는 IoC 컨테이너 또는 DI 컨테이너라고 부른다. 앞으로는 AppConfig 대신 DI 컨테이너라고 명명하겠다.

 

 

-다음 장에서는 본격적으로 스프링에 관해 알아본다.

 

* 해당 글은 'Infleran'의 김영한 강사님의 자료를 참조하였습니다.