새로운 할인 정책 개발 - 다형성 덕분에 새로운 정률할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없음 새로운 할인 정책의 문제점 - 새로 개발한 정률할인정택을 적용하려고 하니 클라이언트 코드 인 주문 서비스 구현체도 함께 변경해야함 - 주문 서비스 클라이언트가 인터페이스인 `DiscountPolicy` 뿐만 아니라, 구체 클래스인 `FixDiscountPolicy` 도 함께 의존 -> DIP위반 관심사의 분리 - 애플리케이션을 하나의 공연으로 생각 - 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고, 실행함 - 비유를 하면 기존에는 남자주인공 배우가 공연도 하고, 동시에 여배우도 직정 초빙하는 다양한 택임을 가지고 있었음 - 공연 구성, 담당배우 섭외,지정하는 책임을 담당하는 ..
새로운 구조와 할인 정책 적용 - 처음으로 돌아가서 정액할인 정책을 정률 (%) 할인 정책으로 변경해보자. - FixDiscountPolicy > RateDiscountPolicy : 어떤 부분만 변경하면 될까? "AppConfig"의 등장으로 애플리케이션이 크게 사용영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 따라서 구성영역의 코드만 고치면 됨 !!! - `FixDiscountPolicy` > `RateDiscountPolicy` 로 변경해도 구성 영역만 영향을 받고, 사용영역은 전혀 영향을 받지 않는다. package hello.core; import hello.core.discount.DiscountPolicy; import hello.core.discount...
관심사의 분리 - 애플리케이션을 하나의 공연이라 생각해보자. 각각의 인터페이스를 배역(배우역할)이라 생각했을때, 실제 배역 맞는 배우를 선택하는 것은 누구인가? - 로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할 지 줄리엣 역할을 누가 할지는 배우들이 정하는것이 아님 - 이전 코드는 마치 로미오 역할 (인터페이스)을 하는 레오나르도 딭카프리오(구현체,배우)가 줄리엣 역할(인터페이스)을 하는 여자주인공(구현체, 배우)을 직접 초빙하는 것과 같았음. - 디카프리오는 공연도 해야하고 동시에 여자주인공도 공연에 직접 초빙해야하는 "다양한 책임"을 가지고 있었다. >> 관심사를 분리하자 - 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야한다. - 디카프리오는 어떤 여자주인공이 선택되더라도 똑같이 공연을 ..
https://start.spring.io/ 우선 위 사이트에 접속해서 스프링 초기 환경설정을 해준 뒤 GENERATE 버튼을 눌러서 다운받아준다. (설정은 위 화면과 동일하게 하였는데, 추후에 버전이 바뀌게 되어 현재와 버전이 다를수도 있다. 그럴땐 그 상황에서의 가장 안정적인 버전으로 하면 되는데, 그 기준은 (SNAPSHOT) 이 붙이 않은 것이 기준이며, 3.xx 는 자바 17을 써야하기때문에 나는 11이 이미 깔려있어서 그냥 2.7 버전으로 했다.) 그리고 의존은 일부러 쌩으로 해보기 위해 하나도 안넣었다. 그러면 진짜 찐 기본 라이브러리만 받아진다. 압축된 파일을 풀어주고 파일 안으로 들어가보면 build.gradle이 있다. 그것을 인텔리제이 혹은 이클립스에서 열어주고 빌드 및 라이브러리 다..
📌 스프링 이야기에 왜 객체지향 이야기가 나오는가 ? - 스프링은 다음 기술로 다형성 + OCP,DIP를 가능하게 지원 ✔️ DI(Dependency Injection) : 의존관계, 의존성주입 ✔️ DI 컨테이너 제공 > 자바 객체들을 컨테이너 안에 넣어놓고 의존관계를 주입하고 제어해줌 - 클라이언트 코드의 변경없이 기능 확장 - 쉽게 부품을 교체하듯이 개발할 수 있음 📌 스프링이 없던 시절 - 옛날 어떤 개발자가 좋은 객체지향개발을 하려고 OCP,DIP 원칙을 지키면서 개발을 해보니, 배보다 배꼽이 크다. 그래서 프레임 워크로 만들어버림 - 순수하게 자바로 OCP,DIP 원칙들을 지키면서 개발을 해보면, 결국 스프링프레임워크를 만들게 된다 (정확히는 DI컨테이너) - DI개념은 말로 설명해도 이해가 ..
SOLID 클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리 - SRP (Single responsibility principle): 단일 책임 원칙 - OCP(Open/closed principle) : 개방-폐쇄 원칙 - LSP(Liskov substitution principle) : 리스코프 치환 원칙 - ISP(Interface segregation principle) : 인터페이스 분리 원칙 - DIP(Dependency inversion principle) : 의존관계 역전 원칙 SRP (Single responsibility principle) 단일 책임 원칙 - 하나의 클래스는 하나의 책임만 가져야 한다. - 하나의 책임이라는 것은 모호하다. > 클 수 있고, 작..