스프링 입문 공부이지만 스프링을 사용하지 않은 순수 자바로만 구현하는 것을 시작으로 한다.
그 이후 하나씩 스프링을 활용한 코드를 추가하고, 환경이 변경되는 과정을 밟으며 다형성과 DI 등을 공부함에 목적이 있다.

◆ 작업 환경

• JAVA 11
• IDE : Intelli J
• Web Framework : Spring
• OS : Windows

◆ 프로젝트생성 (환경설정)

1. start.spring.io에서 Gradle Project, Vers = 안정적인 최신판, Artifact = core, Packaging = Jar, Java = 11 사용
2. 압축풀고 build.gradle을 open (build 코드 변경 시 reload 필수)
3. setttings에서 build Tools의 Gradle의 run, test를 IntelliJ로 변경 (직접 실행으로 빠른 속도)

◆ 비즈니스 요구사항과 설계

• 회원
  회원을 가입하고 조회할 수 있다.
  회원은 일반과 VIP 두 가지 등급이 있다.
  회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)
• 주문과 할인 정책
  회원은 상품을 주문할 수 있다.
  회원 등급에 따라 할인 정책을 적용할 수 있다.
  할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
  할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)
  ( 도메인 협력관계, 클래스 다이어그램, 객체 다이어그램 등을 프로그램 설계 시, 필수적으로 작성)

저장소 구현 방법 1. 내부 메모리 사용 (DB의 변경 가능성을 열어둠)

1. domain 생성
   -1. member 패키지 생성
   -2. Grade를 enum을 생성 (BASIC, VIP)
   -3. Member 엔티티 생성 (Long id, String name, Grade grade)
2. repository 생성
   -1. repository 패키지 생성
   -2. MemberRepository 인터페이스 생성
   void save(Member), Member findById(Long)
   -3. 상속받아 MemoryMemberRepository 구현체 생성
   private static HashMap store = new HashMap<>();
   (내부 메모리를 사용하므로 HashMap형태의 store 생성 – 동시성 이슈로 인해 concurrent HashMap을 사용해야 하나 테스트용이므로 생략)
   save() : store.put(member.getId(), member)
   findById() : return store.get(memberId)
3. service 생성
   -1. service 패키지 생성
   -2. MemberService 인터페이스 생성
   void join(Member), Meber findMember(Long)
   -3. 상속받아 MemberServiceImpl 구현체 생성
   MemberRepository Type으로 MemoryMemberRepository 객체 생성 ( m = new)
   join() : m.save()
   findMember() : return m.findById(id)
4. Member join JUnit Test
   -1. test 파일에 member 패키지 생성
   -2. MemberServiceTest 작성
   new MemberServiceImpl
   @Test
   void join(){
   // given : new Member()
   // when : mService.join() mService.find()
   // then : Assertions.assertThat(member).isEqualTo(findMember) – 두 객체가 같은지 비교
   (Assertions는 org.asserj.core… 을 사용) << 주문도메인 사진>>
5. 할인 정책 인터페이스와 정액 정책 구현체
   -1. discount 패키지 생성
   -2. DiscountPolicy 인터페이스 작성
   int discount(Member, Int) : return 할인 금액
   -3. 상속받아 FixDiscountPolicy 구현체 작성
   discountFixAmount = 1000 // 반환할 고정 할인 금액
   discount() : if(member.getGrade() == Grade.VIP) {1000} else {0} // enum은 ==을 통해 동일 비교
6. 주문 엔티티
   -1. order 패키지 생성
   -2. Order 엔티티 작성
   private memberId, itemName, itemPrice, discountPrice
   생성자 + Getter,Setter
7. 주문 서비스 인터페이스와 구현체
   -1. order 패키지에 OrderService 인터페이스 작성
   Order createOrder(Long memberId, String itemName, int itmePrice)
   -2. 상속받아 OrderServiceImpl 구현체 작성
   미리 만들어둔 memberRepository와 discountPolicy의 구현체를 new로 생성
   public Order createOrder(Long memberId, String itemName, int itemPrice) {
   Member member = memberRepository.findById(memberId); // member 찾기
   int discountPrice = discountPolicy.discount(member,itemPrice); // member 등급에 맞는 할인 금액 반환
   return new Order(memberId,itemName,itemPrice,discountPrice); // 주문 return
   }
   // 참고사항 : 여기서는 discout 정책과 관련되어 구현된 것이 없어, 차후 정책 변경이 유리 (SOLID 중요성)
8. createOrder Test
   MemberService memberService = new MemberServiceImpl();
   OrderService orderService = new OrderServiceImpl();
   @Test
   void createOrder(){
   //given : new Member(), join() // VIP
   //when : createOrder()
   //then : Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000)
   (VIP로 생성된 Member의 할인 금액이 1000원인지 비교)

객체지향 설계 원칙을 잘 준수했는지 확인하기위해 정액 할인 정책에서 정률 할인 정책으로 변경
(기존의 OrderServiceImpl에서 FixDiscountPolicy를 RateDiscountPolicy로 생성 – 다른 코드는 수정 X)

1. 정률 할인 정책 구현체 작성
   -1. 기존의 DiscountPolicy 인터페이스를 상속하여 RateDiscountPolicy 생성
   -2. private int discountPercent = 10 : 할인률 10%
   -3. 정액 할인과 똑같이 작성
   if(member.grade==Grade.VIP){} else {}
   -4. Ctrl+Shift+T로 Test Class 생성
2. Test
   DiscountPolicy discountPolicy = new RateDiscountPolicy();
   @Test // 정상 범위 테스트
   @DisplayName(“VIP는 10% 할인이 적용되어야 한다.”) // Test 결과 출력은 한글로 확인 가능
   void vip_o(){
   //given : new Member
   //when : discount
   //then : Assertions.assertThat(discount).isEqualTo(1000);
   (10% 할인된 금액인 1000원이 맞는지 비교)
   // 참고사항 : Grade를 BASIC으로 설정한 Member가 할인이 적용되지는 않았는지 Test 또한 필요함
3. 기존 시스템에 할인 정책 교체 적용
   -1. OrderServiceImpl에서 할인 정책을 가져올 때, 단순히 변경
   new FixDiscountPolicy() –> new RateDiscountPolicy();
   

@ 문제점 발견
우리는 역할과 구현을 충실하게 분리했다. OK
다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. OK
OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다

• 그렇게 보이지만 사실은 아니다.

DIP: 주문서비스 클라이언트( OrderServiceImpl )는 DiscountPolicy 인터페이스에 의존하면서 DIP를지킨 것 같은데?

• 클래스 의존관계를 분석해 보자. 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고있다.
  — 추상(인터페이스) 의존: DiscountPolicy
  — 구체(구현) 클래스: FixDiscountPolicy , RateDiscountPolicy
• 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 따라서 OCP를 위반한다.

왜 클라이언트 코드를 변경해야 할까?
클래스 다이어그램으로 의존관계를 분석해보자.

지금까지 단순히 DiscountPolicy 인터페이스만 의존한다고 생각했다.

잘보면 클라이언트인 OrderServiceImpl 이 DiscountPolicy 인터페이스 뿐만 아니라
FixDiscountPolicy 인 구체 클래스도 함께 의존하고 있다. 실제 코드를 보면 의존하고 있다! DIP 위반

중요!: 그래서 FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 의 소스 코드도 함께 변경해야 한다! OCP 위반

어떻게 문제를 해결할 수 있을가?
클라이언트 코드인 OrderServiceImpl 은 DiscountPolicy 의 인터페이스 뿐만 아니라 구체 클래스도함께 의존한다.
그래서 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 한다.
DIP 위반 추상에만 의존하도록 변경(인터페이스에만 의존)
DIP를 위반하지 않도록 인터페이스에만 의존하도록 의존관계를 변경하면 된다.
인터페이스에만 의존하도록 설계를 변경하자

인터페이스에만 의존하도록 코드 변경
public class OrderServiceImpl implements OrderService {
//private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
private DiscountPolicy discountPolicy;
}
인터페이스에만 의존하도록 설계와 코드를 변경했다.
그런데 구현체가 없는데 어떻게 코드를 실행할 수 있을까?
실제 실행을 해보면 NPE(null pointer exception)가 발생한다.

해결방안
—이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해주어야 한다.—

◆ 관심사의 분리

AppConfig 등장
애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자

1. Appconfig 작성 (애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는
   별도의 설정 클래스)

• AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
  MemberServiceImpl
  MemoryMemberRepository
  OrderServiceImpl FixDiscountPolicy
• AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.
  MemberServiceImpl MemoryMemberRepository
  OrderServiceImpl MemoryMemberRepository , FixDiscountPolicy

설계 변경으로 MemberServiceImpl 은 MemoryMemberRepository 를 의존하지 않는다!
단지 MemberRepository 인터페이스만 의존한다.
MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서결정 된다.
MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다

객체의 생성과 연결은 AppConfig 가 담당한다.
DIP 완성: MemberServiceImpl 은 MemberRepository 인 추상에만 의존하면 된다. 이제 구체 클래스를 몰라도 된다.
관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다.

◆ 정리
AppConfig를 통해서 관심사를 확실하게 분리했다.
AppConfig는 공연 기획자다.
AppConfig는 구체 클래스를 선택한다. 배역에 맞는 담당 배우를 선택한다. 애플리케이션이 어떻게 동작해야 할지 전체 구성을 책임진다.
이제 각 배우들은 담당 기능을 실행하는 책임만 지면 된다.
OrderServiceImpl 은 기능을 실행하는 책임만 지면 된다.

◆ 금주의 IntelliJ 단축키

• java파일에서 psvm을 치면 자동으로 작성
  public static void main(String[] args) { }
• sout : System.out.println()
• Alit + Insert : 생성자와 Getter,Setter는 물론 toString() 또한 자동 생성 가능
  (구현체 자체를 출력 시, 작성된 toString()이 호출하여 print()가능
• Ctrl + Shift + T : 해단 메서드 Test Class 자동 생성
• Ctrl + E : 프로젝트 내 파일이나 메서드 검색을 통한 이동

◆ 그 외 사항

포스팅 계획 – 3월 : 스프링 / 4월 : 정처기 실기(+중간) / 5월 : 스프링 / 6월 : 졸업 작품(+기말) / 7월 : 스프링 / 8월 ~ : 알고리즘과 CS, JPA, 스프링부트를 포함한 미정

• 아직 해당 작성글에 틀린 부분이 많은 것으로 예상됩니다. 언제나 댓글 환영입니다
• 그리고 이 글은 인프런 김영한 선생님의 Spring 로드맵 과정입니다