스프링 핵심원리 기본편1 - 스프링으로 이름을 지은이유

안녕하세요 스프링 공부를 하며 처음으로 글을 올립니다.

회사 점심 시간마다 하고 있어 진도는 느리지만 천천히 끝까지 완주하고 스프링을 잘하게 되는것이 목표입니다.

일단 지금은 강의가 어느 정도 진행되어 간단한 정리와 설명을 써놓겠습니다.

강의 내용중 인상 깊었던 것은  스프링이라는 단어가 계속 힘들었던 과거의 코더들이 조금더 편하게 개발을 하기 위해 만든 프레임워크를 힘들었던 겨울이 가고 봄이 온다는 의미를 담아 지었다고 합니다.

또 지금은 스프링을 사용 하지 않고 순수 자바로 회원과 주문 관련 기능을 구현하고 있습니다 .

테스트의 중요성을 강조하시며 테스트를 잘할수 있는 방법까지 소개를 해주셔서 많이 배우고 있습니다.

강의를 들으며 느낀점은 웹을 3년전에 만들어보고 3년만에 다시 공부하는 저도 알기 쉽게 강의를 만들어 주셨다는 것이었습니다.

저 처럼 간만에 다시 공부를 시작하는 사람이나 초심자에게 아래 강의를 추천합니다

 

수업에서 김영한 님이 객체 지향의 원리를 생각하다 보면 스프링이 생긴 이유를 알 수 있다고 하셨는데
 
아직 저의 수준으로는 무슨소리인지를 모르겠지만 계속 공부하다 보면 알게 될 거라고 생각합니다.
 
또 애자일 소프트 웨어 개발 선언이라는 것을 보여주었는데 거기서 계획에 따르기보단 변화에 대응하기를
 
이라는 문구가 있었고 금일 수업 내용인 고정 할인 정책에서 비율 할인 정책으로 변경하는 내용을 배우니 
 
많이 공감이 가는 내용이었습니다.
 
discount 패키지에 RateDsicountPolicy 클래스를 만들어 둔 뒤 앞서 만든 DiscountPolicy 인터페이스를 Implemnts 해주어 
 
요구 조건이었던 vip 손님에게 특정비율(ex)10%)를 할인해 줄 수 있는 클래스를 만들어 주었고 
 
그 다음 test를 진행하였습니다.

 

인터페이스를 Implemnts 해주기 위해서는 아래와 같이 Override를 해주어야 합니다.

 

1 2 3 4 5 6 7 8 9

public class RateDiscountPolicy implements DiscountPolicy{       @Override public int discount(Member member, int price) { return 0; } } Colored by Color Scripter

cs

 

인터페이스를 Implemnts시 Override가 필요한 이유는 다음에 다시 정리해 보도록 하겠습니다.
 
테스트에서 사용되는 어노테이션인 @Test와 assert관련 기능들 또 Assertions을 static import 하여 
 
Assertions.assertThat(discount).isEqualTo(1000); 이런 식으로 사용하던 코드가
 
assertThat(discount).isEqualTo(1000); 이렇게 간단하게 바뀌는 것을 알려 주었는데 
 
저는 해당 기능을 몰라 그냥 따라 쳤습니다.
 
주말이나 시간이 날때 해당 기능을 공부하여 정리해 올리는 시간을 가져 조금 더 많은 코드들을 이해할 수 있도록
 
공부를 해야 할꺼같습니다.

 

계속 강의를 진행하며 새로 만든 RateDiscountPolicy를 적용하여 새로운 할인 정책을 변경하는 수업을 따라가 보았습니다.

 

저번 수업으로 RateDiscountPolicy 로직은 만들어 두었고 해당 로직을 OrderServiceImpl에 적용시켜 주기 위해서는 

아래와 같이 OrderServiceImpl에서 기존의 정액 할인 로직을 주석처리하고 새로운 할인 정책을 활성화 시켜 주어야 합니다.

1 2 3

private final MemberRepository memberRepository = new MemoryMemberRepository(); // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy();

cs

 

위처럼 만든 코드는 2개의 문제점이 발견된다고 합니다.

 

일단 역할과 구현을 충실하게 분리하였고 다형성 활용 인터페이스와 구현객체를 분리했습니다.

하지만 OCP와 DIP 원직에 벗어났다고 합니다.

 

위반 사항

OCP : 추상(인터페이스)뿐만 아니라 구체(구현) 클레스에 의존하고 있다. 

DIP : 기능 확장 변경시 클라이언트 코드에 영향을 준다.

*위의 단어는 객체지향 설계 원칙 중에 있는 내용입니다. 해당 내용 역시 다음에 정리해서 올리도록 하겠습니다.

 

위의 위반사항을 해결하기 위해서는 아래와 같은 코드로 변경시켜 주어야 합니다.

*final은 무조껀 값이 할당되어야 해서 삭제

1 2 3 4

private final MemberRepository memberRepository = new MemoryMemberRepository(); // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); // private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); private DiscountPolicy discountPolicy; //final은 무조껀 값이 할당되어야함

cs

 

하지만 위 소스로 돌리면 널 포인트 익셉션이 발생합니다.
누군가가 클라이언트 오더서비스 인플레에 디스카운트 폴리시 구현객체를 누군가 생성하여 주입해주어야 합니다.

 

위의 기능을 추가하는 부분은 다음 개시글에서 작성하도록 하겠습니다.

 

지금까지 들었던 강의에서 해주신 말씀 중 기억에 남는 부분은

 

"테스트를 할 때는 성공뿐만 아니라 반례 즉 실패 건도같이해주어야 한다"

 

입니다. 지금 하는 일에서도 성공건만 테스트하였는데 앞으로는 실패건도

 

같이 테스트를 해주어야겠습니다.

*해당 카타고리의 내용은 아래 링크의 김영한님의 강의를 토대로 느낀점과 배운점을 작성하였습니다
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 | 김영한 - 인프런