본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 9일차!
오늘은 커뮤니티 피드 서비스의 게시글 및 댓글 서비스를 구현하는 실습을 진행하였다.
강사님께서 구현 중에 도메인 클래스에 정적 팩토리 메소드 패턴을 적용시켜서 코드를 작성하셨다. 잊고 있었던 정적 팩토리 메소드 패턴에 대해 다시 한번 공부해보고자 더 자세한 내용을 찾아보았다.
정적 팩토리 메소드 패턴이란 개발자가 구현한 static 메소드를 통해 간접적으로 생성자를 호출하는 디자인 패턴을 말한다.
그렇다면 여기서 의문이 생길 것이다. (내가 그랬다ㅋㅋㅋ)
왜 생성자를 바로 호출하지 않고 굳이 한 단계를 더 거쳐서 객체를 생성하는 걸까?
정적 팩토리 메소드는 메소드명이 클래스명으로 고정되어 있는 생성자와 달리 생성 목적에 대한 이름 표현이 가능하다. 가독성과 유지보수성이 좋아지는 것이다.
도메인에 DTO를 의존시키는 것은 객체지향에서 지양해야 하는 안티 패턴이다.
고수준 모듈인 도메인이 저수준 모듈인 dto에 의존하게 되고, 변경에 취약한 구조가 된다. 또한 도메인의 테스트 코드를 구현할 때에도 dto를 필수로 만들어야 하고, 이는 불필요한 외부 의존성을 끌어들이게 된다.
강사님께서는 이러한 문제를 해결하기 위해 빌더 패턴을 사용하여 메소드 체이닝 방식으로 작성하거나, 객체를 좀 더 작은 객체로 나누어 생성자가 1~2개 이상의 상태값을 가지지 못하게 설계하는 것이 좋은 방법이라고 말하셨다.
그동안 객체지향적으로 설계하지 못하고 계속해서 기능을 추가하다 보니 도메인과 dto의 경계가 모호해지고, 결국 도메인에 dto를 의존시키는 형태의 코드를 꽤나 많이 작성해왔던 것 같다.
지금까지 작업을 할 때 테스트 코드가 왜 이리 길어지지? 원래 이렇게 많은 의존성이 필요한가? 와 같은 의문이 들었던 원인을 알게 되었다.
강의를 한 편씩 들을 때마다 객체지향적인 코드 작성이 얼마나 중요한 것인지 깨닫게 된다.