개발 진행 시 고민해야할 점

새로운 정책이 필요할 경우 고려사항

새로운 정책이 진행되거나 개발이 필요할 때마다 추가로 코드를 이용해서 개발하는 것 자체는 문제가 없습니다. 그러나 새로운 정책을 적용하려고 할 때마다 클라이언트 코드인 서비스 구현체도 함께 변경이 되어야합니다.
그러나 주문 서비스 클라이언트가 인터페이스뿐 아니라 구현 클래스도 함께 의존할 경우 DIP위반이라는 문제가 발생합니다.

관심사의 분리

애플리케이션을 하나의 공연으로 생각해야합니다. 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고 실행했었습니다. 예시를 들면 기존에 남자 주인공 배우가 공연과 동시에 여자 주인공도 직접 섭외를 하는 등의 다양한 책임을 가지고 있었습니다.
그렇기 때문에 공연을 구성하고, 담당 배우를 섭외하고, 지정하는 책임을 담당하는 별도의 "공연 기획자"가 필요합니다. 그러므로 config를 이용합니다.
이 config는 애플리케이션의 전체 동작방식을 구성하기 위해, 구현 객체를 생성하고 연결하는 책임을 가지고 있습니다. 이렇게 설정을 해놓을경우, 클라이언트 객체는 자신의 역할을 수행하는 것만 집중하며, 권한이 줄어들어 책임이 명확해집니다.

config리펙터링

구성 정보에서 역할과 구현을 명확하게 분리해야합니다. 이렇게 리펙터링을 하게 된다면 역할을 잘 확인할 수 있으며, 중복을 제거할 수 있습니다.

새로운 정책의 적용

위와 같이 구조를 설계해놓을 경우에는 새로운 정책을 개발하더라도, Config파일만 수정하면, 클라이언트 코드인 서비스 코드는 변경하지 않아도 됩니다.