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

관심사를 분리하자 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다. 공연 기획자는 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당해야 한다. 이렇게 공연 기획자와 배우의 책임과 역할이 분리되어 있다. AppConfig 등장(공연 기획자) 애플리케이션의 전체 동작 방식을 구성(config) 하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들어야 한다!! public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderServic..

새로운 할인 정책 개발 저번 예제에서는 고정 할인을 해주었다. 하지만 기획자가 새로운 할인 정책을 해달라고 했다고 가정해보자. 고정 할인이 아닌 10% 할인이다. 차분하게 생각해보면 구현채만 바꾸면 된다. RateDiscountPolicy 구현 public class RateDiscountPolicy implements DiscountPolicy { private int discountPercent = 10; @Override public int discount(Member member, int price) { if (member.getGrade() == Grade.VIP) { return price * discountPercent / 100; } else { return 0; } } } 간단하게 Tes..

비즈니스 요구사항 설계 회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) -> interface 주문과 할인 정책 회원은 상품을 주문할 수 있다 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) -> interface 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하자!! 회원 도메인 설계(..

SOLID SRP : 단일 책임 원칙(single responsibility principle) OCP : 개방-폐쇄 원칙 (Open/closed principle) LSP : 리스코프 치환 원칙 (Liskov substitution principle) ISP : 인터페이스 분리 원칙 (Interface segregation principle) DIP : 의존관계 역전 원칙 (Dependency inversion principle) SRP 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 모호하다. 책임이 클 수도 있고, 작을 수도 있다. 문맥과 상황에 따라 다르다. 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다. OCP 개방..

객체 지향 프로그래밍이란? 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. (협력) 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프 트웨어 개발에 많이 사용된다 다형성 실세계와 객체 지향을 1:1로 매칭하지 않는다. 그래도 실세계의 비유로 이해하기에는 좋다. 역할과 구현으로 세상을 구분한다. 마치 자동차를 다른 것으로 바꿔도 운전면허를 새로 안 따도 되는 것과 비슷하다. 대상을 바꾸지 않고 새로운 자동차를 만들 수 있다. 즉 client의 영향을 주지 않고 새로운 기능을 줄 수 있다. 역할과 구현을 분..