스프링 핵심 원리 기본편(3) - 객체 지향 원리 적용
1. 새로운 할인 정책 개발
- 주문한 금액의 %를 할인해주는 새로운 정률 할인 정책을 추가하자.
1-1 RateDiscountPolicy 코드 추가
package hello.core.discount;
import hello.core.member.Grade;
import hello.core.member.Member;
public class RateDiscountPolicy implements DiscountPolicy{
private int discountPercent = 10;
@Override
public int discount(Member mebmer, int price) {
if(mebmer.getGrade() == Grade.VIP){
return price * discountPercent / 100;
}else {
return 0;
}
}
}- GRADE가 VIP인 경우 가격 * 10/100 을 수행해서 리턴해줌
1-2 Test 작성
- Ctrl + Shift + T 를 누르면 테스트 작성을 바로 할 수 있다.
- 테스트 라이브러리는 JUnit5로 설정한다.
package hello.core.discount;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;
class RateDiscountPolicyTest {
RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
@Test
@DisplayName("VIP는 10%의 할인이 적용되어야 한다.")
void vip_o() {
//given
Member member = new Member(1L, "memberVIP", Grade.VIP);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(1000);
}
@Test
@DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
void vip_x() {
//given
Member member = new Member(1L, "memberBASIC", Grade.BASIC);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(0);
}
}- Assertions는 static import로 생략 (assertThat 메서드)
- @DisplayName은 JUnit5 부터 추가된 기능
- VIP인 경우 할인이 제대로 적용 되는지, VIP가 아닌경우 할인이 적용이 안되는지 테스트
할인정책을 추가하고 테스트까지 완료
2. 새로운 할인 정책 적용과 문제점
- 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야 한다.
💡 **문제점 발견**
- 우리는 역할과 구현을 충실하게 분리했다. OK
- 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. OK
- OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다
→ 그렇게 보이지만 사실은 아니다 - DIP: 주문서비스 클라이언트( OrderServiceImpl )는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지켰는가?
→ 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다- 추상(인터페이스) : DiscountPolicy
- 구체(구현) 클래스 : FixDiscountPolicy, RateDiscountPolicy
- OCP: 변경하지 않고 확장할 수 있는가?
- 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 따라서 OCP를 위반한다
- FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl의 소스 코드도 함께 변경해야 한다!
→ OCP 위반
2-1 문제를 해결하는 방법
인터페이스에만 의존하도록 코드 변경
package hello.core.order;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository = new MemoryMemberRepository();
private DiscountPolicy discountPolicy;
@Override
public Order createOrder(Long memberId, String itemName, int itemPrice) {
Member member = memberRepository.findById(memberId); //회원 정보 조회
int discountPrice = discountPolicy.discount(member, itemPrice); //할인 정책 적용
return new Order(memberId, itemName, itemPrice, discountPrice); // 주문 객체 생성후 반환
}
}- 그런데 구현체가 없는데 어떻게 코드를 실행할 수 있을까?
→ 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해야 한다.
3. 관심사의 분리 → 중요!
3-1 AppConfig 생성
package hello.core;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
public MemberService memberService(){
return new MemberServiceImpl(new MemoryMemberRepository());
}
public OrderService orderService() {
return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
}
}- AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
- MemberServiceImpl
- MemoryMemberRepository
- OrderServiceImpl
- FixDiscountPolicy
- AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.
- MemberServiceImpl → MemoryMemberRepository
- OrderServiceImpl → MemoryMemberRepository , FixDiscountPolicy
3-2 MemberServiceImpl : 생성자 주입
package hello.core.member;
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
public MemberServiceImpl(MemberRepository memberRepository) { // MemberServiceImpl생성자
this.memberRepository = memberRepository; // 생성자로 memberRepository구현체를 주입 받음
}
@Override
public void join(Member member) {
memberRepository.save(member);
}
@Override
public Member findMember(Long memberId) {
return memberRepository.findById(memberId);
}
}- MemberServiceImpl의 생성자로 MemberRepository 객체를 주입 받는다.
- MemberServiceImpl 입장에서 생성자를 통해 어떤 MemberRepository 구현 객체가 들어올지(주입될지)는 알 수 없다.
- MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서
결정된다 - MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.
3-3 OrderServiceImpl : 생성자 주입
package hello.core.order;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository; //생성자로 memberRepository 구현체를 주입 받음
this.discountPolicy = discountPolicy; //생성자로 discountPolicy 구현체를주입 받음
}
@Override
public Order createOrder(Long memberId, String itemName, int itemPrice) {
Member member = memberRepository.findById(memberId); //회원 정보 조회
int discountPrice = discountPolicy.discount(member, itemPrice); //할인 정책 적용
return new Order(memberId, itemName, itemPrice, discountPrice); // 주문 객체 생성후 반환
}
}- OrderServiceImpl의 생성자로 MemberRepository 객체와 DiscountPolicy 객체를 주입 받는다.
- OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
- OrderServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서
결정된다 - OrderServiceImpl 은 이제부터 실행에만 집중하면 된다.
클래스 다이어그램
- 객체의 생성과 연결은 AppConfig 가 담당한다.
- DIP 완성: MemberServiceImpl 은 MemberRepository 인 추상에만 의존하면 된다. 이제 구체 클래스를
몰라도 된다. - 관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다
- appConfig객체는 MemberRepository를 구현하는 memoryMemberRepository객체를 생성하고, 그 참조값을 memberServiceImpl 을 생성하면서 생성자로 전달
- 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependendy Injection) 의존성 주입 이라고 한다.
4. AppConfig 실행
4-1 사용클래스 : MemberApp 수정
package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
public class MemberApp {
public static void main(String[] args) {
AppConfig appConfig = new AppConfig(); //AppConfig객체 생성
MemberService memberService = appConfig.memberService(); //appConfig에서 MemberService객체를 받음
Member member = new Member(1L, "memberA", Grade.VIP);
memberService.join(member);
Member findMember = memberService.findMember(1L);
System.out.println("new member = " + member.getName());
System.out.println("find Member = " + findMember.getId());
}
}- 이제 memberServiceImpl 객체를 바로 받는것이 아니고, appConfig객체의 메서드를 통해서 memberService 인터페이스의 구현객체를 받는다.
4-2 OrderApp
package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
public class OrderApp {
public static void main(String[] args) {
AppConfig appConfig = new AppConfig(); //AppConfig객체 생성
MemberService memberService = appConfig.memberService(); //appConfig에서 MemberService 구현객체를 받음
OrderService orderService = appConfig.orderService(); //appConfig에서 orderService 구현객체를 받음
Long memberId = 1L;
Member member = new Member(memberId, "memberA", Grade.VIP);
memberService.join(member);
Order order = orderService.createOrder(memberId, "itemA", 10000);
System.out.println("order = " + order);
System.out.println("order.calculatePrice = " + order.calculatePrice());
}
}- OrderApp도 AppConfig를 통해서 memberService, orderService 인터페이스의 구현객체들을 받는다.
4-3 테스트 코드 수정
MemberServiceTest
package hello.core.member;
import hello.core.AppConfig;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
public class MemberServiceTest {
MemberService memberService;
@BeforeEach //다른 메서드를 실행하기전에 객체생성 후 메서드가 끝나면 생성한 객체를 제거해줌
public void beforeEach(){
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
}
@Test
void join(){
//given
Member member = new Member(1L,"memberA", Grade.VIP);
//when
memberService.join(member);
Member findMember = memberService.findMember(1L);
//then
Assertions.assertThat(member).isEqualTo(findMember);
}
}OrderServiceTest
package hello.core.order;
import hello.core.AppConfig;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
public class OrderServiceTest {
MemberService memberService;
OrderService orderService;
@BeforeEach //다른 메서드를 실행하기전에 객체생성 후 메서드가 끝나면 생성한 객체를 제거해줌
public void beforeEach(){
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
orderService = appConfig.orderService();
}
@Test
void createOrder(){
Long memberId = 1L;
Member member = new Member(memberId, "memberA", Grade.VIP);
memberService.join(member);
Order order = orderService.createOrder(memberId, "itemA", 10000);
Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
}
}
테스트가 잘 되는 모습을 볼 수 있다.
5. 정리
- AppConfig를 통해서 관심사 분리를 진행함.
- AppConfig는 구체 클래스를 선택해서 기능을 수행하는 클래스에게 던져 준다.
- 이제 기능을 수행하는 클래스들은 기능만 수행하는 책임만 지면 된다.
AppConfig를 배우면서 각 기능들 간에 서로 영향을 주지 않고 클래스들을 구현하려고 하는 개발자들의 생각을 알 수 있었다.
스프링을 사용하지않은 객체지향적인 코드만 봐도 엄청 잘 만든거같은데, 스프링을 사용하면 어떨지 기대가 된다!
반응형