221108 TIL Value Object를 활용하자

오늘도 아샬 님이 오셔서 라이브 코딩을 하며 여러 가지 꿀팁을 전달해주시고 가는데 그중에서 오늘 내 코드에 적용한 것들만 정리해 봤다.

 

Controller는 간단하게

Controller는 최대한 간단하게 만드는 게 좋다고 해주셨다. 그에 반해 나의 Controller는 상당히 복잡했다. 그 이유가 post라는 게시글에 전달해줘야 할 정보가 post객체뿐만 아니라 comment 같은 부가적인 객체들도 같이 전달해줘야 했기 때문에 여러 서비스를 호출해서 전달해줬는데 이것 때문에 복잡한 Controller가 만들어진 것이었다.
controller를 최대한 간단하게 만들기 위해서 하나의 Action에서는 하나의 Application Service가 호출되어야 한다. 그래서 여러 개의 서비스를 불러서 전달해주던 구조를 하나씩만 전달하게 리팩터링 해주니 controller가 상당히 간단해졌다.

 

Value Object를 활용하자

이후 Value Object를 활용해 객체를 나누는 작업을 했는데 처음에는 어떤 것이 도메인 모델이 되어야 하고 어떤 것이 값 객체가 돼야 하는지 잘 구별이 안돼서 값 객체를 만들지 않고 있었는데 오늘 아샬 님의 설명을 들으면서 어떤 상황에 사용하면 좋은지 단번에 깨달을 수 있었다.
바로 나의 코드에서 값 객체로 만들어서 사용할 수 있는 게 없을까 찾다가 post객체에 제목과 내용은 게시글의 정보라고 생각해 게시글의 제목과 내용을 포함한 PostInformation라는 값 객체 만들었다.

 

 
근데 기존의 작성했던 코드가 많아 객체에서 한 부분을 바꾸니 이곳저곳에서 바꿔달라고 하는데 수정하는 시간도 만만치 않았다.
처음부터 제대로 설계했다면 어땠을까 라는 생각도 했지만 처음부터 제대로 설계하는 건 지금 레벨에서 쉽지 않다고 말하셔서 계속 수정 해나 가는 건 어쩔 수 없는 것 같다. 지금 수정하는 게 나중에 프로그램이 더 커졌을 때 하는 것보다는 덜 고통스러우니까.. 미래의 나를 위해서라도 최대한 지금 리팩터링을 제대로 하고 가자

 

중복을 줄이자

그리고 이전에 강의에서 배웠던 static을 이용해 테스트를 위한 메서드를 만들어서 테스트에서 중복을 방지하는 방법이 있었다는 것을 다시 상기시킬 수 있었다.

그리고 값 객체가 위 코드에서 1L이 의미하는 바가 직관적으로 드러나지 않기 때문에 값 객체로 만들어서 new UserId(1L)처럼 어떤 것이 1L인지 알려주는 용도로도 값 객체를 활용할 수 있다고 하셨다.

테스트 코드를 작성하면서 post 같은 객체는 쓰는 곳도 많고 갖고 있는 정보도 많아서 하나씩 써줄 때마다 귀찮았었는데 static으로 fake메스드를 하나 만들면 테스트할 때마다 쓸 수 있어 매우 유용하다.

Post 객체를 테스트하기 위해서 하나씩 위처럼 길던 코드가 아까 만들어준 fake메서드를 활용하면 아래 사진처럼 엄청 간단해진다.

 

 

오늘도 아샬 님이 말씀해주신 것들을 최대한 코드에 반영하기 위해 대대적인 리팩터링이 이루어지는 중이다.

기능 구현도 중요하지만 제대로 만드는 것도 중요하기 때문에 리팩터링 할게 발견이 되었을 때 미루지 않고 리팩터링 하고 가는 게 가장 좋은 것 같다.