이번 시간에는 관심사의 분리에 관하여 알아보는 시간을 가졌다.
이전 시간에 배운것과 같이, 예를 들어서, 자동차를 예로 들어서 역할과 구현을 분리하는 것과 같은 내용이었다.
이미 이전 시간에 배운것과 동일한 개념이니, 자세한 설명은 이전에 작성한 포스트를 참고해주세요~~
[섹션 1. 객체 지향 설계와 스프링] 좋은 객체 지향 프로그래밍이란?(+다형성이란?)/ 인프런 김영
이번 시간에는 좋은 객체 지향 프로그래밍이 무엇인지 알아보는 시간을 가졌다. 객체 지향의 특징으로는, 추상화, 캡슐화, 상속, 다형성과 같은 특징들을 가지고 있다. 객체 지향 프로그래밍이
easpop.tistory.com
추가로 설명을 하자면, 로미오와 줄리엣 이라는 공연에서 맡고 있는 로미오라는 역할이 있을 것이고,
또한 로미오를 맡고 있는 배우가 있을 것이다.
여기서 로미오의 역할이 인터페이스가 되는 것이고, 배우는 그 역할을 수행하는 구현체가 될 것이다.
그렇기 때문에, 역할에 맞는 배우를 지정하기 위해서는 공연 기획자가 필요할 것이다.
이 공연 기획자 역할을 스프링에서 AppConfig가 해준다!
애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고,
연결하는 책임을 가지는 별도의 설정 클래스를 생성해줄 것이다.
hello.core 하위에 AppConfig 클래스를 생성해준다.
MemberService를 호출해준다.
이전의 코드는 MemberServiceImpl 클래스에서 인터페이스가 구현체를 직접 호출했었다.
이건 마치 위의 공연을 예로 든 예시에서, 배우(구현체)가 직접 상대 배우(다른 구현체)를 지정하는 것과 같음!
위와 같은 기존의 코드에서,
new 연산자를 없애주고, 생성자를 통해서 주입 받을수 있도록 생성자를 만들어준다~~
그리고 다시 AppConfig로 돌아와서,
다른 곳에서 Appconfig를 통해서 memberService를 호출할 것이다.
그러면 리턴값으로 MemberServiceImpl 구현체가 생성이 되는데,
MemoryMemberRepository를 파라미터 값으로 넣어준다.
아까 작성한 MemberServiceImpl 클래스를 들어가보면, 위의 그림에서의 흐름과 같이,
생성자를 통해서 들어와서 memberRepository에 할당이 된다.
이렇게 되면 MemberServiceImpl에는 MemoryMemberRepository에 대한 코드가 없고,
MemberRepository 인터페이스만 있으므로, 추상화에만 의존한다고 할 수 있다~!
AppConfig클래스에 OrderService도 만들어준다.
그리고 마찬가지로 생성자 주입을 할 것이다.
생성자를 만들어주기 위해 OrderServiceImpl 클래스로 이동한다.
OrderService는 memberRepository도 필요하고, discountPolicy도 필요하기 때문에,
생성자를 통해 둘 다 주입을 받아준다~~
AppConfig로 이동해서 OrderService 메소드를 코딩해준다~~
흐름을 정리해보자면 위의 그림과 같다!
orderService 메소드에서 new 연산자를 생성해서 리턴값으로 OrderServiceImpl의 파라미터로 넣어준다.
그리고 1번과 같이 생성자를 통해서 파라미터를 받아서, 2번과 같이 인터페이스에 주입해준다~~!
결론적으로, memberRepository에는 메모리에 저장하는 구현체인 MemoryMemberRepository가 주입되고,
discountPolicy에는 고정할인 정책 구현체인 FixDiscountPolicy가 주입되게 된다!
이렇게 되면 OrderServiceImpl 입장에서는 어떤 구현체가 들어오는지 전혀 모르기 때문에,
추상화에만 의존하고 있다고 할 수 있다~~!
다시 AppConfig로 돌아와서,
AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성하는 역할을 한다.
또한, 생성한 객체 인스턴스의 참조를 생성자를 통해서 주입받는다.
MemberServiceImpl의 경우에는, new MemoryMemberRepository를 통해서 객체를 생성하고, 이 참조값을
MemberServiceImpl 클래스에서, 생성자의 파라미터인 memberRepository에 넣어준다~~
즉, AppConfig는 애플리케이션의 환경을 구성하는 역할을 하는 클래스이고 (위의 공연 예시에서 공연 기획자 역할),
AppConfig를 통해서 어떤 구현 객체가 주입될지 정해진다.
이렇게 객체를 생성하고 연결하는 역할과 실행하는 역할이 분리되었기 떄문에, 이를 관심사의 분리라고 할 수 있다!
기존의 MemberApp 클래스를 보면, 여기서 memberService를 직접 생성했는데,
위의 그림과 같이, appConfig를 호출해서, appConfig를 통해서 memberService에 접근하는 구조로 변경이 되었다~~!
OrderApp도 마찬가지로, 위와 같은 기존의 코드에서,
아래와 같이 appConfig를 통해서 Service를 호출할 수 있도록 변경해준다.
메소드 실행 결과 정상 작동~~
MemberServiceTest, OrderServiceTest, 두개의 테스트 코드도 역시 appConfig를 통해서 접근하도록 코드를 변경해주고,
전체 테스트 결과 둘 다 정상 작동하는 것을 확인할 수 있다!
이렇게 이번 시간에는 AppConfig를 통해서 관심사를 분리하였다~~
댓글