221206 어드민 활동 로그를 생성할 때 Event를 부여하는 방법

하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.

스케줄 상 오늘 내로는 admin 단 서비스의 CSS를 거의 완성하다 시피 해야 하는 상황인데 생각보다 진척도가 늦다.
TIL을 쓰기 전 '왜 그러지?' 라는 생각을 했는데 가만보니 오늘 오후시간 까지 어드민 활동 로그 로직을 만지고 있었다는 사실을 발견했다.

어드민 서비스는 초기 기획안에 내용이 없었던지라 서비스 구현 직전에 간이 기획을 해가면서 만들어가고 있다.
그렇다보니 막상 CSS를 적용하면서 보완해야 할 점이 너무나 눈에 많이 띄고 있음.. ㅠㅠ. 기획안이 이렇게나 중요한 것이었나 싶을만큼 그 중요성을 뼈저리게 느낀다.
하여튼 이 촉박한 시간 속에서도 방향을 잃지 않기 위해 오늘도 화이트보드에 간략히 판서를 시작하고 CSS에 돌입했다.

어제 마무리 짓지 못한 어드민 활동 로그 로직을 마무리 하면서 CSS를 적용하고 있는데 문득 서버측에서 로그를 생성할 때 '이렇게 하는건 적절하지 않다'는 생각이 드는 지점이 있었다.

// DeleteUserReviewService.java

AdminLog createdAdminLog = new AdminLog(foundAdmin.id(), new Event(200L, "deleteUserReview"), reason);

AdminLog, 즉 어드민 활동 로그는 어드민의 id, 밸류 오브젝트인 Event(이벤트 코드, 이벤트 명), 어드민이 작성한 사유(reason)로 구성되는데 이를 서비스에서 생성할 때 하드코딩으로 만들자니 '다른 사람들이 이걸 쉽게 알아볼 수 있을까?' 라는 생각이 들었다.

쉽게 알아볼 수 있는건 물론이거니와, 만약에 코드나 이벤트 명이 바뀌었을 경우 모든 서비스를 찾아다니면서 수정해야 하는 부적절한 상황이 발생할 수 있단 생각도 들었다.

뭔가 묘수가 떠오르지 않다가 예전에 테스트의 편의를 위해 fake 객체를 만든 방법을 활용해보면 어떨까 하여 아래와 같이 리팩터링을 해보고 질문을 남기기로 결정했다.

// Event.java

public static Event deleteUserReview() {
        return new Event(200L, "deleteUserReview");
    }

public static Event deletePlace() {
        return new Event(201L, "deletePlace");
    }

// DeleteUserReviewService.java

AdminLog createdAdminLog = new AdminLog(foundAdmin.id(), Event.deleteUserReview(), reason);

아샬님께서 답변을 달아주셨는데 아주 일반적이고 좋은 방법이라고 하시면서 이펙티브 자바 아이템 1번에 대한 내용을 말씀해주셨다. 다음에 읽을까? 하고 넘어가려다가 마침 눈앞에 이 책이 있어서 말씀하신 아이템 1번에 대한 내용을 읽어봤는데... 와우. 마음이 조급해서 그런지 눈에 잘 안들어오기도 하고 무슨 이야기인지 잘 이해가 가지 않았다 ㅎㅎㅎㅎㅎ

이렇게 포트폴리오 주간이 끝나고 읽을 책이 하나 더 추가...되는건가...ㅎ.
자바 개발자라면 반드시 읽어야 하는 책이라고 하니 포트폴리오 끝나면 바로 사서 같이 스터디 하자고 얘기해야겠다.
우선 책에 나온 내용을 옮겨 적으면 아래와 같다.

---

• public 생성자
  클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단
• 정적 팩터리 메서드(static factory method)
  생성자와는 별도로 클래스의 인스턴스를 반환하는 단순한 정적 메서드

정적 팩터리 메서드가 생성자보다 좋은 장점 다섯가지
1. 이름을 가질 수 있다.
2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.
3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

---

다른건 잘 모르겠는데 1번 만큼은 내가 fake를 떠올린 이유에 딱 들어맞는다.
단순히 하드 코딩으로 "deleteUserReview"를 넣을 때보다, 해당 엔티티에서 의미가 드러나는 이름을 가진 정적 팩터리 메서드를 활용하니 (1) 변동사항이 생겼을 때 그 곳에서 수정을 하면 되고, (2) 말 그대로 이름을 가질 수 있는 상태가 되었다.

나는 유독 강의에 나온 내용들을 코드 구현에 적용시키기 어려워하는 편인데 오늘 fake를 떠올렸다는 사실이 뭔가 신기하기도, 아주 살짝 뿌듯하기도 했다.
조금 어려운 책들이지만 이펙티브 자바와 같은 책들을 보면서 내가 추상적으로 알고 있었던 것들을 이론과 같이 접목시키며 코드에 적용시키고 싶단 욕심도 생긴 하루였다.

어드민 페이지 CSS..!! 우선 깔끔하게 하는 것을 목표로 로그인 페이지와 장소 목록 페이지, 그리고 신규 장소 생성 페이지만 구현한 상태...
조금 느리지만. 그래도 오늘 안에 마무리한다는 마음으로 진도를 뺴보자!!!!
엉뚱하게 header를 사이드 메뉴로 빼는 과정에서 시간이 많이 걸렸다.. ㅠㅠ흑. 아쉽.

그래도 꿋꿋하게. 쭈-욱.... 가자. 가자. 가자...!

• 로그인 페이지
  

• 장소 관리 메뉴의 장소 전체목록 페이지
  

• 장소 관리 메뉴의 신규 장소 추가하기 페이지