오늘이라도

강의 링크 1. 제어의 역전 IoC (Inversion of Control) - 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. - 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. - 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다..

강의 링크 1. SRP 단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야 한다. - 클라이언트 객체는 직접 구현 객체를 생성하고, 실행하는 다양한 책임을 가지고 있음 - SRP 단일 책임 원칙을 따르면서 관심사를 분리함 - 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당 - 클라이언트 객체는 실행하는 책임만 담당 2. DIP 의존관계 역전 원칙 : 프로그래머는 "추상화에 의존해야 하지, 구체화에 의존하면 안 된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다. - 새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했다. 왜냐하면 기존 클라이언트 코드(OrderServiceImpl)는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는..

강의 링크 0. 전체 흐름 정리 - 새로운 할인 정책 개발 - 새로운 할인 정책 적용과 문제점 - 관심사의 분리 - AppConfig 리팩터링 - 새로운 구조와 할인 정책 적용 1. 새로운 할인 정책 개발 - 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없음 2. 새로운 할인 정책 적용과 문제점 - 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야함 - 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy 뿐만 아니라, 구체 클래스인 FixDiscountPolicy 도 함께 의존 => DIP 위반 3. 관심사의 분리 - 애플리케이션을 하나의 공연으로 생각 - 기존에는 클라이언가 의존하는 서버 구현 객체를 ..

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 새로운 구조와 할인 정책 적용 - 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자. - FixDiscountPolicy → RateDiscountPolicy - 어떤 부분만 변경하면 되겠는가? => AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. - FixDiscountPolicy → RateDiscountPolicy로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않는다. - AppConfig에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy → RateDiscountPolicy객체로 변경했다..

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ - extract new method : ctrl + alt + m3 1. AppConfig 리팩터링 현재 AppConfig를 보면 "중복"이 있고, "역할"에 따른 "구현"이 잘 안보인다. - 중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링한다. - new MemoryMemberRepository() 부분이 중복 제거되었다. - 이제 MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 된다. - AppConfig를 보면 역할과 구현 클래스가 한 눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 관심사의 분리 - 애플리케이션을 하나의 공연이라 생각해 보자. 각각의 인터페이스를 배역(배우 역할)이라 생각하자. 그런데 실제 배역을 맡는 배우는 누가 선택하는가? - 누가 남주인공을 하고 여주인공을 할지를 배우들이 정하는 것이 아니다. - 이전 코드는 남주인공역할(인터페이스)을 맡은 레오나르도 디카프리오(구현체, 배우)가 여주인공 역할(인터페이스)을 하는 배우(구현체)를 직접 초빙하는 것과 같다, - 이 경우에 디카프리오는 공연도 해야 하고 여주인공 배우도 직접 초빙해야 하는 다양한 책임을 가지고 있다. 2. 관심사를 분리하자 - 배우는 본인의 역할인 배역을 수행하는 것만 집중해야 한다. - 디카프리오는 어떤 여자 주인공이 선택되더라도 ..