헤맨 만큼 내 땅이다

RetentionPolicy와 AOP에 대한 고찰관심을 가지게 된 이유'땅콩' 프로젝트에서 '방 생성'시 쿠키를 발급하는 로직이 있었다.이때 쿠키 발급 로직이 '방 컨트롤러'에 구현되어 있었다.OOP 관점에서 책임 분리의 필요성을 느꼈고 세션 관리 로직을 AOP로 리팩터링 하도록 결정하였다.이 과정에서 AspectJ를 활용하여 AOP를 구현하였다.@IssueCookie라는 커스텀 애노테이션을 만들어 해당 애노테이션이 있는 경우 비즈니스 로직 호출이 완료된 이후 쿠키를 발급하는 로직이 호출되도록 설정하였다.의문점 발생문제 상황나는 서버가 실행되고 있는 중 '방 생성 API'가 호출될 때, 이를 처리하는 createRoom 메서드에 애노테이션을 보고 쿠키 로직이 호출된다고 생각하였다. 그래서 런타임까지 애노..

배경방 참여 및 방 생성 작업 시 쿠키를 발급하여 유저 정보를 세션 관리하고 있었다.(방 참여 API에서 쿠키를 저장하는 로직을 호출한다.)하지만, 쿠키를 발급하는 로직을 RoomMemberCookieEncryptor와 같은 필드로 컨트롤러에 가지고 있고, 쿠키를 설정하고 지우는 작업을 컨트롤러가 가지고 있는 것은 책임 분리 측면에서 부적절하다고 판단하였다. 이에 따라, 쿠키 설정 및 삭제 로직을 컨트롤러에서 분리하여 관리할 필요성을 느끼게 되었다.(RoomController에서 쿠키를 설정하고 삭제하는 로직이 구현되어 있다) 이를 해결하기 위해 다음 세 가지 방안을 고려하였다.대안1. Filter필터는 J2EE 표준 스펙으로, 디스패처 서블릿에 전달되기 전후에 URL 패턴에 맞는 모든 요청에 대해 부가..

예외 메시지를 어떻게 관리하면 좋을까? 우테코 레벨 1 미션을 진행 중 예외 메시지를 처리하는 과정에 예외 메시지를 별도로 관리해 주는 것이 좋을지 고민이 되었다. 미션을 진행하는 중에는 "일단 메시지를 직접 넣어주고 나중에 리팩터링하자" 라는 생각에 위와 같이 일단 예외 메시지를 직접 넣어주었다. 그리고 기능을 구현한 이후 다시 찾아와서 고민을 하였다. 예외 메시지를 별도의 상수로 관리해주는게 좋을까?? 예외 메시지를 별도로 관리하는 방식 나는 과거에 프리코스 동안 진행했던 미션에서는 모든 메시지를 상수로 관리해 주었다. 왜 이때는 별도의 객체에서 관리해 주는 방식을 선택했을까?? 당시에 이 방식을 선택한 이유는 다음과 같다. 1. 변경 사항이 발생했을 때 수정하기 편리하다. 비슷한 예외 메시지를 사용..

서론 ebook으로 책을 구매한 이후 굿노트에서 필기하면서 보고 싶었다. pdf 로 구하고 싶었으나 pdf 파일을 구하려면 직접 캡처하는 것 말고는 딱히 방법이 없었다. 그래도 몇 백 페이지나 되는 책을 일일이 캡처하는 것은 여간 귀찮은 일이 아니다. 그래서 알아서 캡쳐해주는 프로그램을 만들게 되었다. 물론, 책을 캡쳐하여 영리를 취하는 행위는 불법이다. 그러나 개인적인 목적으로 감상, 복습, 학습의 목적으로 파일 저장하여 출력하는 경우에는 저작권을 침해하는 경우가 아니라고 본다. 따라서 행여나 해당 프로그램을 활용해서 영리 목적으로 판매 및 공유를 하는 일은 안 하는 게 좋다. + 또한 Python을 통해 프로그램을 실행하기 때문에 개발자가 아닌 경우는 사용하기 어려울 수 있다. 구현 과정 구현 과정은..