[Review] 2022/04/06 1차 PR

 

1. 질문

팀원과 처음 Work라는 도메인 모델을 만들때 2가지 방식의 생성방법에 대하여 논의 하게 되었습니다.

1. 생성자 방식
2. 빌더패턴

1) 생성자 이용하기

public class Work {
    // 생략...

    public Work(String title, String content, String author) {
        this.title = title;
        this.content = content;
        this.author = author;
        this.workStatus = WorkStatus.TODO; // 초기값 자동 지정
        this.createDateTime = LocalDateTime.now(); // 초기값 자동 지정
        this.lastModifiedDateTime = createDateTime; // 초기값 자동 지정
    }

위 방식은 Controller로 request DTO가 전달 돠었을 때 필요한 값 3개만 뽑아서 생성하는 방식 입니다.
추가로 나중에 DB 에서 꺼내 올때는 위 생성자로 생성 한 후, 날짜는 setter를 통해 다음과 같이 호출할 생각 이였습니다.

Work work = new Work();
work.setCreateTime();
work.setLastUpdateTime();

을 호출하여 DB에서 꺼내올 생각 이였습니다!

 

2) 빌더 패턴 이용하기
두번째로는 builder 패턴을 사용하는 방식 입니다. 해당 도메인이 field값이 많아져서 빌더로 메서드를 호출하면 가독성이 증가할거라 생각되었습니다.
나중에 DB에서 꺼내올때도 하나씩 인자를 다 지정할수도 있구요!

일단은 생성자 방식을 사용했는데... 음 리뷰어님이라면 어떤 방식을 선택하실것 같나요??

 

Roach는 다음과 같이 답변해 주셨다!

 

2. 코드 리뷰

1. Domain의 getter 사용에 대한 고찰

우선 팀원과 만든 Work라는 domain의 모든 필드값에 대하여 getter를 열어주고 있었다.

왜냐하면 처음 화면을 로딩할 때, iOS 측으로 모든 Work에 대한 데이터를 넘겨줘야 하기 때문이다.

 

직접적으로 domain 을 바로 Controller에서 반환하는 것 은 아니지만,

어찌됬던 domain -> dto -> Response body 에 담아 보내려면 domain의 모든 정보들을 dto에 담아야 했으며, 이를 전달하기 위해 모든 필드에 대하여 getter를 열어주고 있었다.

 

다만 이렇게 모든 정보를 전달해야 했을지? 이에 대한 의문을 팀원과 조금더 의논 해봐야 겠다.

 

2. Controller에서의 반환 타입 통일 시키기

우리의 컨트롤러는 일부분 에서는 ResponseEntity.ok().body()를 사용했고, 일부분 에서는 ResponseEntity<>() 를 사용하였다.

이를 ResponseEntity.ok().body() 으로 조금 더 통일 시켜 사용하기로 하였다!

 

3. 의미없는 Wrapping 하지 말기

우리의 workSerivce가 workSave()를 통해 반환한 workSaveResponse는 이미 dto의 역할을 하고 있다.

따라서 바로 workSaveResponse를 반환해도 되는 상황 이였다.

 

하지만 이를 ResponseEntitiy로 한번더 Wrapping 하여 iOS 측에 전달하게 되었다.

사실상 의미없는 포장에 불과했다... 이런점 주의하자!