츈츈's Spring

AppConfig 리펙터링 수정전 public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(new MemoryMemberRepository(),new FixDiscountPolicy()); } } 문제점 위의 AppConfig 클래스는 역할과 구현이 한눈에 보이지 않는다. 역할과 구현이 한눈에 보이지 않는다라는 말을 아래의 두 코드로 이해해보자 return new MemberServiceImpl(new MemoryMemberRe..

관심사의 분리 각각의 인터페이스를 배역(배우 역할)이라고 생각해보자. 이때 역할에 맞는 배우들은 누가 선택할까? 누가 로미오 역할을 할지는 배우들이 선택하는것이 아니다. 이전 코드는 마치 로미오 역할을 하는 디카프리오가 줄리엣 역할을 하는 여자주인공을 직접 선택한 것과 같다. 디카프리오는 공연도 해야하고 여자주인공도 선택해야하는 다양한 책임을 갖게 되는것이다. 코드로 설명해본다면 인터페이스의 구현체인 MemberServiceImpl가 저장소 인터페이스의 구현체를 직접 선택한다는 것이다. 이때 필요한 것이 " 관심사를 분리" 하는 것이다. 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야한다. 디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연할 수 있어야한다. 이를 위해서 배역에 맞는 배우들을 ..

할인 정책을 FixDiscount -> RateDiscount로 바꾸게 된다면 어떤 문제가 발생할까? 문제점 새로운 할인 정책으로 바꾸게 된다면 클라이언트 코드에서 수정이 불가피하다. //private final DiscountPolicy discountPolicy= new FixDiscountPolicy(); private final DiscountPolicy discountPolicy= new RateDiscountPolicy(); 왜 수정이 불가피 한가? 해당 코드는 인터페이스 뿐만아니라 구체화된 클래스에도 의존하고 있기 때문에 DIP원칙을 위배하게 되어 새로운 정책을 적용시키기 위해서 OCP 원칙 마저 위배하게 되는 것이다. 해결방안 그렇다면 DIP를 위반하지 않도록 인터페이스에만 의존하도록 코드..

좋은 객체 지향 설계의 5가지 원칙 SRP 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다 중요한 기준은 변경이다. 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른것. 변경이 필요할 때 한 클래스의 수정만으로 수행이 가능하도록 해야한다 ★ OCP 개방-폐쇄 원칙 확장에는 열려있으나 변경에는 닫혀 있어야 한다. 확장을 하려면 당연히 기존의 코드 변경이 필요하지 않나? → 다형성을 이용 MemberService 클라이언트가 구현 클래스를 직접 선택함 따라서 구현 객체를 변경하려면 클라이언트 코드를 변경해야함 분명 다형성을 사용했지만 OCP원칙을 지킬 수는 없음 클라이언트가 기존의 코드를 변경해야함 !! MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존하고 있다..

스프링 부트 스프링 프레임워크(스프링)를 사용하기 편리하도록 도와주는 것이 스프링 부트이다. 스프링 부트가 웹 서버를 내장하기 때문에 별도의 웹서버를 설치하지 않아도 됨 스프링을 예전에는 직접 라이브러리를 가져와야했는데 스프링 부트가 이제는 알아서 필요한 라이브러리를 가져옴 스프링 부트는 스프링 프레임워크와 별도로 사용할 수 있는 것이 아님 스프링에 필요한 설정 부분을 스프링 부트가 대신 모두 설정해주는 것 기본적으로 스프링 프레임워크와 스프링 부트를 같이 사용해서 개발을 하는 것 스프링 스프링 DI 컨테이너 기술 스프링 프레임 워크 스프링 부트,스프링 프레임 워크를 모두 포함한 의미 스프링의 핵심 개념 이 기술은 왜 만들었는가? 이 기술의 핵심 컨셉은? 스프링은 객체 지향 언어인 자바 기반의 프레임워크..