[Refactor] feat: 전역 예외 처리 추가 및 URL 단축 로직 분리 #22
Conversation
| @ExceptionHandler(NotFoundShortenUrlException.class) | ||
| public ResponseEntity<String> handleNotFoundShortenUrlException(NotFoundShortenUrlException ex) { | ||
| return new ResponseEntity<>("단축 URL을 찾지 못했습니다.", HttpStatus.NOT_FOUND); | ||
| } |
There was a problem hiding this comment.
추후 정의되는 예외가 추가됨에 따라, json 형식의 에러 코드와 메시지를 포함한 응답을 생성할 예정입니다.
| return String.valueOf(RANDOM.nextInt(10000)); | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
현재 UrlShortenService에서만 사용되기 때문에 빈 등록을 제거하였습니다.
There was a problem hiding this comment.
URL 단축 방식이 변경되고 다양한 메서드가 추가될 가능성을 고려하여 객체로 생성하였습니다. 현재는 shorten() 메서드만 사용하기 때문에 객체로 생성하지 않아도 될 것 같아 static 메서드로 변경하였습니다.
UrlShortener 클래스에 shorten() 이외의 여러 가지 메서드가 추가된다면, 객체를 생성할지 말지는 클래스 내에 상태를 가지는지 여부에 따라 판단하는 것이 맞는지 궁금합니다.
There was a problem hiding this comment.
현재는 shorten() 메서드만 사용하기 때문에 객체로 생성하지 않아도 될 것 같습니다. 그렇다면 static 메서드로 구현하는 것이 맞을까요?
저는 지금의 상황이면 util 성격으로 간주하여 static method 로 만들 것 같습니다.
UrlShortener 클래스에 shorten() 이외의 여러 가지 메서드가 추가된다면,
미래는 불특정하기에 지금에 맞는 클래스 형태를 권장 합니다.
- ex) 클래스 안에 메서드를 추가하는게 아니라, provider 를 여러개 만들어서 필요에 따라 사용한다.
객체를 생성할지 말지는 클래스 내에 상태를 가지는지 여부에 따라 판단하는 것이 맞는지 궁금합니다.
이건 질문 이해가 잘 안되네요. 상태 보유 여부를 떠나서 런타임에 dto 외의 객체를 생성하는 케이스는 거의 없지 않나요?
There was a problem hiding this comment.
객체를 생성할지 말지는 클래스 내에 상태를 가지는지 여부에 따라 판단하는 것이 맞는지 궁금합니다.
제가 이해를 잘못한 것 같습니다. static method로 사용하고 추후 구현에 따라 궁금한 점이 생기면 다시 질문드리겠습니다!
| public GetOriginUrlResponse(String originUrl) { | ||
| this.originUrl = originUrl; | ||
| } | ||
| } |
There was a problem hiding this comment.
record가 더 간결하고 가독성이 좋다고 생각되어 변경하였습니다.
Hyune-c
changed the title
| return String.valueOf(RANDOM.nextInt(10000)); | ||
| } | ||
|
|
||
| } |
feat: 전역 예외 처리 추가 및 URL 단축 로직 분리
전역 예외 처리 추가
패키지 구조 변경 및 URL 단축 로직 분리