Editor....를 활용한 패턴에 질문있습니다.

Question

당연히 구글링 해보셨져? 원하는 결과를 못찾으셨나요? 어떤 검색어를 입력했는지 알려주세 문제가 발생한 코드(프로젝트)를 Github에 올리시고 링크를 알려주세요. Editor관련한 질문글들을 읽어보아도 제 머리로 이해가 안돼서 또 이렇게 Editor 질문 글을 하나 더 추가합니다... ㅠㅠ  [해당 영상을 보지 않았더라면 짰을 코드] Post엔티티에 비즈니스 로직을 작성하고 단순하게 PostEdit을 전부 넘겨 비즈니스 로직 change를 호출하여 더티체킹으로 마무리! 이렇게 했을 경우, 파라미터 순서에 무관하게 PostEdit이라는 수정을 위한 Dto 객체를 단 하나만 넘겨 수정을 할 수 있다고 판단했습니다. 물론 위 비즈니스 로직은 null값에 대처는 못하겠지만요! 하지만, 프론트 개발자와 상의하여 '수정 시, 모든 데이터를 넘겨준다는 전제' 에서는 가장 간단한 방법이라고 생각했습니다!  [Editor를 작성해보며 느낀 의문점] Post의 toEdit을 통해 기존 가지고 있던 데이터를 PostEditor에게 넘김으로써 Builder에서 null값에 대응할 수 있다는 점 이외에는 또 다른 장점을 이해하지 못하고 있습니다. Request의 title혹은 content가 null일 경우 이를 해결하기 위한 방법을 제시해주는 것 말고는 되려 관리해야 할 것들만 늘어난 느낌이 해소가 되지 않습니다 ㅠㅠ 그래서 제가 이해한 것 까지의 내용들이 잘 이해한 것인지 그리고 추가적으로 제가 이해하지 못한 것들을 이해하고 싶습니다!  findById로 수정하려는 엔티티를 가져옵니다. toEdit()을 통해 현재 수정하고자 하는 엔티티의 필드들을 PostEditor에게 넘겨 빌더를 만듭니다. 이는 수정하려는 엔티티가 현재 가지고 있는 필드들을 핸들링 할 수 있도록 해줍니다. (가령, title혹은 content의 null 처리) 2번을 통해서 PostEditor가 현재 수정하려는 Post의 필드들을 주입 받았으면, Request로 받은 데이터를 통해 최종 build()를 해줍니다. 변경사항을 모두 적용한 postEditor를 Post의 변경비즈니스 메서드 edit(postEditor)를 통해 더티체킹으로 변경해줍니다.   [최종적으로 든 생각] [Editor를 작성해보며 느낀 의문점] 에서 작성된 것들이 정확하다면,아예 첫 방법을 사용하되, 비즈니스 메서드에서 null 체크를 해주면 어떨까? 하는 생각이 들었습니다. 이런 방식으로 진행한다면 문제가 있을까요? 긴 글에 시간 내어주셔서 감사합니다 !

ovg07047 · Answer

https://www.inflearn.com/course/lecture?courseSlug=%ED%98%B8%EB%8F%8C%EB%A7%A8-%EC%9A%94%EC%A0%88%EB%B3%B5%ED%86%B5-%EA%B0%9C%EB%B0%9C%EC%87%BC&unitId=111160&category=questionDetail&tab=community&q=647518 더 찾아보니 위 질문글에서 1번 코드에 대한 피드백이 제 궁금증에 가장 가까운 답변이었습니다! 하지만, 그럼에도 제 지식이 따라가지 못하는 것 같아 아쉽네요 ㅠ   Post가 서비스 정책인 PostEdit을 아는 것과 Post가 PostEditor아는 것의 큰 차이를 못 느끼겠습니다..   PostEdit도 수정을 위해서 만든 정책이기에 같은 형태인 PostEditor를 하나 더 만들기 보다는 어차피 테스트에서 PostEditor를 알아야 하듯, PostEdit을 알아야하는 것과 큰 차이가 있는 것인가요?!   설계적인 측면에서 PostEdit을 '서비스정책'이고 PostEditor는 그렇지 않음에서 오는 관심사를 완벽히 분리하고자 하는 것이 목적일까요?