[기본기] 5-5. 이제 리팩토링

본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.

이전 시간 관심사를 분리하기 위하여서 기획자의 역할인 AppConfig라는 클래스를 만들어 기획자의 입장에서 코드를 만들어봤지만... 이제는 코드를 효율적으로 다시 리팩토링을 해볼 시간이다.

❗ AppConfig 리팩토링하기

📂 AppConfig

Before

public class AppConfig {

    public MemberService memberService(){
        return new MemberServiceImpl(new MemoryMemberRepository());
    }
    public OrderService orderService(){
        return new OrderServiceImpl(new MemoryMemberRepository(),  new FixDiscountPolicy());
    }
}

After

public class AppConfig {
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    public MemberRepository memberRepository(){
        return new MemoryMemberRepository();
    }

    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(),  discountPolicy());

    }
  
    public DiscountPolicy discountPolicy(){
      return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

이게 위 코드와 밑에 코드를 보게 되면은 어찌보면 코드의 길이 상으로는 리팩토링 후의 코드가 더 길어진다는 것을 알 수 있지만 오히려 이제 중복이 더 사라지고 역할을 명확히 구분할 수 있다는 점에 있어서 더 보기 좋아졌다는 측면이 있다.

이게 지금은 코드가 생각보다 짧고 역할의 종류도 많지 않아서 티가 그렇게 안 날수도 있지만 이게 코드의 길이가 어마어마하게 증가를하게 된다면 밑의 방식처럼 memberRepository나 DiscountPolicy와 같이 따로 구분하여 만들어주는 것이 역할이 어떻게 되어있는지 더 명확하게 구분할 수 있다는 장점이 있었다.

출처

1. 김영한님의 스프링 핵심 원리 기본편(https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8)