AppConfig 리팩터링

AppConfig 리팩터링

이번 시간에는 AppConfig를 리팩터링을 해볼게요. 현재 AppConfig를 잘 보시면, 중복도 좀 있고 역할에 따른 구현이 잘 안보여요.

클라이언트가 주문할 때 생각해보시면, 주문 서비스 역할이 있었고, 주문 서비스 역할은 또 회원 저장소 역할이 있고, 할인 정책 역할이 필요했죠.

그래서 역할과 구현을 딱 분리해서 한 그림으로 보고 싶은데, 이 설정 정보, 구성 정보에는 한 그림에 딱 보여야된단 말이에요. 역할이 있고 그 역할에 대한 구현은 어떤 게 있다가 딱 한눈에 보이는 게 되게 중요하거든요.

그런데 지금 AppConfig에는 그런게 전혀 안보여요.

자 그래서 이 역할을 드러나게 만드는게 되게 중요합니다.

MemberService가 있었죠. 그 다음에 MemberRepository라는 역할도 보여야 되는데 지금 전혀 안보이죠.

그래서 new MemoryMemberRepository()을 드래그하고 cmd + option + M 해서,

memberRepository()라는 메서드를 만들겠습니다.

만들면 다른 것도 대체하시겠습니까? 라고 뜨는데,

중복이 있었던 것들을 인텔리제이가 알아서 바꿔줍니다.

이렇게 바꾸고 나면, MemberService 역할, MemberRepository 역할, OrderService 역할이 다 드러나죠.

그리고 나서, 한 가지 더

이렇게 해서 FixDiscountPolicy를 콜하도록 리팩터링 해줍니다.

이렇게 하면, 어떠한 장점이 있냐면

이것만 봐도 지금 여기에 역할이 다 드러나죠. 메서드 반환타입만 봐도 역할이 다 드러납니다.

그리고 memberService에 대한 구현을 "현재 나의 애플리케이션에서는 memberService는 MemberServiceImpl를 쓸거야!", 그리고 memberRepository은 "내 애플리케이션에선 memberRepository는 MemoryMemberRepository을 쓸거야!" 라고 한눈에 알 수 있는거죠.

그럼 만약에 나중에 db에 저장을 해야해서 JdbcMemberRepository로 바꿔요. 그럼 어디만 바꾸면 되죠?

AppConfig의 이 부분만 바꿔주면 되는거에요.

자 그리고 orderService도 보면, "orderServiceImpl를 쓰긴 쓸건데, 현재 내 애플리케이션 memberRepository가 쓰는 걸 가져오고, 현재 내 애플리케이션에서 결정한 discountPolicy 쓰는 걸 가져올거야!" 하면, 알아서 딱 객체가 들어오는 거죠.

그렇게 해서 이 설계에 대한 그림이 저 구성 정보에 그대로 드러나는 거예요. 역할들이 나오고 그 역할에 대한 구현이 어떤 게 되는지가 한눈에 들어오는 거죠.

이렇게 리팩터링을 하는 게 되게 큰 장점이 있습니다. 중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링 한거죠.

---

한번 정리해 보면요.

new MemoryMemberRepository() 이 부분이 중복이 있었는데 제거되었죠. 이전에는 다른 리포지토리로 바꾸려면 중복된 부분을 모두 바꿨어야 했는데, 이제는 MemoryMemberRepository를 다른 구현체로 변경할 때

이 한 부분만 딱 변경하면 됩니다.

그리고 AppConfig를 보면 역할과 구현 클래스가 한눈에 들어오죠. 메서드명이랑 return type을 보면, 역할이 먼저 보입니다. 그리고 이거에 대한 구현 클래스를 return 뒤에서 찾을 수 있습니다. 그래서 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있습니다.

역할을 세우고, 구현이 그 안에 들어가도록 하는 이러한 설계를 하면 좋겠죠. 이렇게 딱 깔끔하게 리팩터링이 됐습니다. 그리고 중복도 제거가 됐구요.

---

다음 시간에는 지금까지 FixDiscountPolicy만 했으니까 이제 RateDiscountPolicy로 드디어 바꿔보겠습니다.