[스프링 핵심 원리 - 기본편] 인프런 강의 정리(예제만들기 - 회원 도메인 설계, 개발, 실행, 테스트)

 

/* 이 글은 김영한님의 강의를 보고 정리하려고 작성한 글입니다.

   개인적인 공부를 위해 올리는 글이므로 중간 중간 코드는 생략되었습니다. */

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

 

 

회원 도메인

 

 

 

1. 회원 도메인 설계

 

회원 도메인 협력 관계

 

◾ 클라이언트의 역할 : 회원서비스 호출

◾ 회원서비스의 역할 : 회원가입 / 회원조희 총 두 가지의 기능

◾ 회원저장소의 역할 : 세가지 저장소 중 하나를 선택하여 회원 관리

                                    [ DB 회원 저장소(자체DB) / 외부 시스템 연동 회원 저장소 ] 

                                    이 둘 중 어떤 저장소를 사용할 지 미확정이기 때문에

                                    메모리 회원 저장소를 만들어 개발을 진행(로컬 개발, 테스트 진행용)

 

 

 

회원 클래스 다이어 그램

 

◾ 회원 서비스 = MemberService <interface>

◾ 회원 서비스의 구현체 = MemberServiceImpl

◾ 회원 저장소 = MemberRepository <interface>

◾ 회원 저장소의 구현체 = MemoryMemberRepository / DbMemberRepository

 

💡 여기서 궁금했던 점

: 저장소는 나중에 교체하기위해 Interface로 추상화 하는건 이해가 가나 Service는 교체 가능성이 없는데 추상화를 하는 이유는? 이 궁금했는데 누군가가 인프런에 질문을 했고, 김영한님이 답변한게 있어서 참조

 

누군가 이 질문을 해주어야 하는데, 하고 기다리고 있던 질문입니다. ㅎㅎ
제가 객체 지향 설계와 스프링 마지막에서 말씀드렸던 내용이 기억나실꺼에요.
* 이상적으로는 모든 설계에 인터페이스를 부여하자

 

실무 고민
* 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다.
* 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고,

  향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.

강의에서는 이상적으로 역할과 구현을 분리하는 것에 초점을 맞추어서 이런 부분들도 분리했습니다.
저도 실무에서는 교체 가능성이 없는 서비스 클래스는 구체 클래스로 바로 만드는 것을 선호합니다^^

 

 

 

 

회원 객체 다이어그램

 

◾ 객체 다이어 그램 : 실제 서버에 올라왔을 때 객체들의 메모리 참조를 그린 것

◾ 결과적으로 우리가 만들어야 하는 그림

 

 

 

 

 

2. 회원 도메인 개발

 

 

MemoryMemberRepository

 

public class MemoryMemberRepository implements MemberRepository{

    private static Map<Long, Member> store = new HashMap<>();

    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }

    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }

}

 

💡 궁금증 1

: store를 만들 때 static을 사용한 이유는?

 

static 을 사용하면 객체를 생성하지 않고 클래스 이름으로 직접 접근할 수 있으며, 오로지 단 한 번만 생성되기 때문에 모든 객체에서 동일한 값으로 사용할 수 있다. 따라서 다른 객체 간에 값을 전달하거나 공유하는데 용이하다.

이러한 static의 특징을 이용하여 단 하나의 Map을 사용하기 위해 static으로 Map을 생성한 것.

만약 static을 제거한다면 new MemberRepository(); 를 작성할 때 마다 새로운 Map이 생성되어 객체마다 다른 값의 Map을 가지게 된다.

 

 

💡 궁금증 2

: store를 HashMap으로 생성했는데 일반적으로 동시성 이슈를 방지하기 위해 ConcurrentHashMap으로 생성하는게 좋다고 하셨다. 예제를 단순하게 하기 위해 HashMap으로 생성했는데 둘의 차이점은?

 

HashMap과 ConcurrentHashMap은 둘다 'key-value' 형태의 데이터를 저장하는 자료구조이다.

 

HashMap

  - 데이터의 삽입, 삭제, 검색등의 연산이 빠르다

  - null 값을 저장할 수 있다

  - 싱글스레드 환경에서 안전하게 사용할 수 있다

 

ConcurrentHashMap

  - 내부적으로 데이터를 분할하여 처리하기 때문에 멀티스레드 환경해서 HashMap보다 더 빠른 속도로 동작한다.

  - null 값을 저장할 수 없다

  - 멀티스레트 환경에서 안전하게 사용할 수 있으며 여러 스레드에서 동시에 접근해도 일관성을 유지한다.

 

 

 

 

 

 

MemberServiceImpl

 

public class MemberServiceImpl implements MemberService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return null;
    }
    
}

 

💡 궁금증 1

: memberRepository를 만들 때 final로 선언한 이유?

 

  ◾ 불변성(Immutability): final 필드는 한 번 초기화되면 값을 변경할 수 없다. 이것은 필드에 대한 안정성을 제공하며, 필드 값을 보호한다. memberRepository가 한 번 설정되면 다른 객체로 변경되지 않도록 보장한다.

  ◾ 스레드 안정성(Thread Safety): final 필드는 다중 스레드 환경에서 안전하게 사용된다. 여러 스레드가 동시에 memberRepository를 수정하려고 시도하는 것을 방지하며, 동시 접근에 대한 문제를 방지한다.

  ◾ 가독성과 유지보수성: final 키워드를 사용하면 코드의 의도가 명확해진다. memberRepository가 한 번 설정되고 변경되지 않는다는 사실은 코드를 읽는 사람에게 중요한 정보를 전달한다.

  ◾ 오류 방지: final로 선언된 필드는 컴파일 시간에 한 번 초기화되며, 런타임 중에 다시 설정되는 오류를 방지한다.

 

 

 

 

 

3. 테스트 코드 작성

 

위치 중요

◾ 나중에 빌드하면 테스트 코드는 빠진다고 함!

 

 

 

 

 

MemberServiceTest

 

package hello.core.member;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

public class MemberServiceTest {

    @Test
    void join() {

        MemberService memberService = new MemberServiceImpl();

        // given
        Member member = new Member(1L, "memberA", Grade.VIP);

        // when
        memberService.join(member);
        Member findMember = memberService.findMember(1L);

        // then
        Assertions.assertThat(member).isEqualTo(findMember);

    }

}

 

◾ Assertions Import할 때 "org.assertj.core.api.Assertions" 이걸로!

 

 

💡 궁금증 1

: Assertions의 기능과 assertThat의 기능 종류

 

Assertions은 테스트 코드에서 사용되며 특정 조건이 참이어야 테스트가 계속 진행되도록 하는 기능이며 assertThat은 다양한 비교 및 검증작업을 수행할 때 사용한다.

assertThat 메서드 종류

String ex1 = "hello wolrd";

String ex2 = "hello wolrd";

◾ assertThat(ex1).isEqualTo(ex2); / isNotEqualTo(ex1); : 두 값이 같은지 / 다른지 비교

◾ assertThat(ex1).isNull(); / isNotNull(); : 값이 null인지 / null이 아닌지 확인

◾ assertThat(ex1).istrue(); / isfalse(); : 값이 true인지 / false인지 확인

◾ assertThat(ex1).startWith("hello") / endsWith("wolrd") : 문자열의 시작, 끝 확인

◾ assertThat(ex1).contains("hello") : 문자열 특정부분에 포함되는지 확인

등등 많으니까 찾아보기

 

 

 

 

4. 설계의 문제점

 

◾ 이 코드는 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있음

 

private final MemberRepository memberRepository = new MemoryMemberRepository();

 

여기서 MemberRepository는 인터페이스에 의존하지만 실제 할당하는 부분은 구현체를 의존하고 있음

추상화에도 의존하고 구현체에도 의존하고 있는 상태 = DIP 위반

➔ 해결 방안은 '주문'까지 만들고 나서 설명해주신다고 함.