perfect dish | 이거 만들어볼까? (3) - 코드 모듈화

🍽 Perfect dish 개발 일지

도메인 설계부터 어떤 기능을 가진 클래스를 만들 건지. 계층구조는 어떻게 만들 건지. 이 메서드는 어디 넣을 건지. 또 이 메서드의 접근 제한은 또 어떻게 해야 할지 등등 고려해야 할게 많다. 

스프링 시큐리티 수업 들으면서 와. 부트 진짜 매력 있다. 이렇게 친절하게 시큐리티를 구현하게 만들어뒀다고? 감동~ 이러면서 했는데 

지금 상태로는 시큐리티까지 갈 수 있을지? (가야지) 

이 글은 개발 여정을 기록한 것으로 틀린 내용이 나올 수 있습니다. 점점 고쳐나가기 때문이죠 

 

💡지금까지의 설계가 완전히 잘 못 됐다. 

db 연결을 하지 않는다는걸 고려하지 못했다.

그래서 뭘 바꿔야 할까?

1. repository를 interface로 만들었으므로 구현체 만들기

2. db 대신 데이터 관리할 곳 정하기 

3. 앞서 (2)에서 repository에 비즈니스 로직을 넣지 않고 Service에 넣으려고 바꾸면서 테스트 코드 전반적인 변경 

mapper 같은 db와 상호작용 처리를 하는 기능을 repo 구현체에 심었다. 

memberService에 repository 구현체가 아닌 interface를 autowired 해 추후 다른 구현체로의 교체가 쉽도록 했다. 

 

 

💡 InMemory로 db 대신 데이터 관리하기 (코드 모듈화 작업)

 

repository의 구현체 의 기능은 단순히 데이터를 저장. 조회 

비즈니스 로직은 Service. 근데 걸리는 메서드가 하나 있다. 

휴대폰 번호로 유저를 찾는 건데 우선은 번호의 뒤 4자리만 추출함. 이는 중복이 나올 수 있다. 그 유저 리스트에서 이름을 비교해서 한 사람만 찾는 기능을 가지는 메서드인데 이걸 어떻게 둘로 나눠야(?) 잘 나눴다고 할까(?) 

내가 생각한 방법은 뒷번호 4자만 추출하는 메서드 A 가 휴대폰 번호로 유저를 찾는 메서드 B 안에 들어가 있는 구조다. 

InMemoryMemberRepository 내에 A 따로 B 따로 두고 Service에서 합쳐야 할지? 
근데 두 메서드를 과연 따로 로직을 짠다고 했을 때?
A :  뒷번호 4자리 추출, B : 폰번호가 같으면 추출 이면
Service 계층에서 B로 1. 폰번호 전부를 추출 -> 2. 뒷번호 4자리만 같은 애들을 추출 -> 3. 이름이 같은 애들 추출 

뭔가 1을 추출하는 비용이 낭비되고 있다. 굳이 전체를 불러오고 그 안에서 filter...? 

 

그래서 메서드 명을 "뒷번호 4개가 같은"을 넣어 목적이 드러나게 바꾸고 아예 처음부터 뒷번호 4자리가 같은 애들만 따로 모아 비교하게 했다.  

그리고 이 메서드와 이름을 비교하는 메서드 C를 따로 두었다. 

 

InMemoryMemberRepository는 단순히 데이터를 저장하고 조회하는 역할만.