kth990303의 코딩 블로그

우리는 객체지향을 배우면서 추상화의 장점을 배운다. Java, Spring에서는 이 장점들을 적극적으로 활용할 수 있도록 굉장히 많은 지원을 해준다. 참고: https://kth990303.tistory.com/359 [JAVA] IoC, DI, DIP 친구와 얘기하던 중, Spring IoC, DIP 개념에 대한 얘기가 나왔다. 이 개념들은 구글링하면 워낙 잘 정리된 글들이 많아 별도로 작성하지 말까 고민도 했다. 하지만 해당 개념들은 객체지향에서 매우 kth990303.tistory.com 인터페이스, 추상클래스, DI 등의 장점에는 의존성이 적어진다는 점이 존재한다. 이러한 점 덕분에 구현을 하다가 if문이 굉장히 많이 나오거나, 추상화할 수 있게 리팩터링할만한 부분이 나온다면 우리는 추상화를 이용..

인증 방법에는 토큰을 이용하는 방식, 세션을 이용하는 방식이 존재한다. 나는 주로 토큰을 이용하는 방식을 선호하는데 그 이유는 아래와 같다. 세션 기반 인증은 쿠키를 사용해야 한다. 그러나 쿠키는 네이티브 앱에서 지원하지 않고 브라우저에서만 사용할 수 있다. 다중 WAS 환경에서 세션은 동기화 이슈가 존재한다. 따라서 확장성이 낮다. sticky session, session clustering 등 다양한 방법이 존재하지만, 토큰 방식은 이러한 점을 고려할 필요가 없다. 물론 토큰 방식은 별도의 구현이 좀 더 필요하지만, 한 번 구현해놓으면 어렵지 않고 편리하게 이용가능하기 때문에 큰 거부감이 없는 편이다. 토큰 방식의 인증은 또 두 가지 방법으로 나뉜다. Access Token만을 이용하는 방식과 Re..

ArgumentResolver는 컨트롤러 단에서 요청값으로부터 원하는 객체 또는 프로퍼티를 반환하게 할 수 있다. 보통은 커스텀 유저 객체를 반환할 때 HandlerMethodArgumentResolver의 구현체를 이용하여 많이 사용한다. Java에서의 ArgumentResolver 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 @Component @RequiredArgsConstructor public class AuthenticationPrincipalArgumentResolver implements HandlerMethodArgumentResolver { private final JwtTokenProvider jwtTokenProvider; @Ov..

프론트 측에서 swagger 문서의 request Body에 required 옵션을 추가해달라는 요청이 들어왔다. 현재는 request에 required 표시인 레드닷(red dot)이 하나도 적용되지 않는 상황이다. 심지어 swagger는 Java와 Kotlin에서 서로 약간 다르게 동작하기도 한다. 어떻게 해야 할까? @ApiParam? @Parameter? Swagger 3.0 버전 이후부터는 @ApiParam이 @Parameter로 변경됐다. import io.swagger.v3.oas.annotations.Parameter 실제로 Java에서는 해당 어노테이션을 적용하면 잘 뜰것이다. 하지만 코틀린은? @Parameter(required=true)로 해봤자 전혀 변함이 없다. 심지어 @field..

Java, Kotlin은 둘 다 JVM 생태계 언어로써 상당히 비슷한 면이 많다. 하지만 둘은 다른 언어다보니, 당연히 다른 점들도 꽤 많이 존재한다. kotlin의 null-safe operator로 편리하고 안전하게 null 관련 처리를 할 수도 있고, 확장함수를 통해 자유롭게 커스터마이징이 가능하며, 다양한 lambda functions를 제공해줌으로써 Java의 stream 기능 못지 않게 간단한 코드를 작성할 수 있다. 그럼 반대로 Java에선 제공해주지만 Kotlin에서는 제공하지 않는 기능이 뭐가 있을까? Java에서는 checked exception을 제공하지만, Kotlin에서는 이를 제공하지 않는다! 이번 포스팅에선 이 내용에 대해 적어보도록 하겠다. Checked Exception? ..

코틀린 프로젝트에서 kotest로 테스트 코드를 짜다가 통과해야 할 테스트가 통과하지 않는 현상을 마주치게 됐다. 우리는 StringSpec과 유사한, 중첩되지 않은 구조에서 Given - When - Then 구조의 BehaviorSpec 스타일로 테스트를 마이그레이션하고 있었다. 위 두 테스트 코드는 아예 동일하다. 그저 계층만 나뉘게 바뀌었을 뿐. 구조에 따라 계층을 나누기만 하고, 순서 변경이라든지 코드의 변경이 없었으니 테스트는 당연히 문제 없이 통과할 줄 알았다. 그런데 결과는? Tests Failed... 당연히 WAITING에서 PASS로 변경될 줄 알았는데 Given에서 진행해준 update가 진행되지 않고 WAITING인 상태로 테스트가 진행됐다. 심지어 코드 변경은 전혀 없고 구조에 ..

스프링에서 코틀린을 사용할 때, 테스트 도구로 JUnit뿐만 아니라 kotest를 사용할 수 있다. kotest는 다양한 테스트 스타일을 제공한다. JUnit과 유사한 Annotation Spec, String Spec, 그리고 우리가 흔히 사용하는 given when then 스타일을 사용할 수 있도록 Behaivor Spec을 제공해주기도 한다. DCI 패턴을 활용할 수 있도록 Describe Spec도 제공해준다. 이번 시간에는 kotest에서 제공해주는 spec을 살펴볼 것이다. kotest의 장점 JUnit, Mockito를 사용할 경우 Kotlin DSL을 사용하지 못한다는 단점이 존재한다. kotest를 활용하면 kotlin DSL을 사용해 더 코틀린스러운 테스트를 작성할 수 있게 된다. 위..

kotlin DSL과 Spring REST Docs 세팅을 MockMvc 방법으로 설정하는 포스팅이다. 환경세팅 및 adoc 형식 설정은 지난 포스팅에서 확인할 수 있다. https://kth990303.tistory.com/347 [Kotlin] Kotlin DSL + Spring REST Docs + MockMvc 적용기 (1) 현재(22.07.17.) 는 아직 Spring REST Docs에서 kotlin DSL 공식지원을 하지 않고 있는 상황이다. https://github.com/spring-projects/spring-restdocs/issues/677 Document how to use Spring REST Docs with th.. kth990303.tistory.com 이번 포스팅에선 k..

현재(22.07.17.) 는 아직 Spring REST Docs에서 kotlin DSL 공식지원을 하지 않고 있는 상황이다. https://github.com/spring-projects/spring-restdocs/issues/677 Document how to use Spring REST Docs with the MockMVC Kotlin DSL · Issue #677 · spring-projects/spring-restdocs Was trying to implement RestDocs MockMvc in our Kotlin project However noticed that when using the MockMvc Kotlin DSL snippets were not generated e.g. fun..

kotlin의 클래스와 메서드는 기본적으로 final이다. 따라서 어떠한 클래스의 상속을 허용하려면 클래스 앞에 open 변경자를 붙여주어야 한다. 상속을 사용하고 싶어서 open 변경자로 클래스를 열어주었는데, 외부에서 무분별하게 상속을 통해 기능을 확장시키는 건 막고 싶을 수 있다. 이러한 경우 Sealed Class를 이용하면 좋다. Sealed Class Operator 인터페이스의 구현체들인 Plus, Minus, Multi 클래스들이 있다. calc 함수는 when절을 이용하여 Plus, Minus, Multi인지 확인하고 결과를 반환하는 함수이다. 만약, 어떤 것에도 해당하지 않으면 else문을 작성해주어야 한다. else문이 없으면 위와 같이 컴파일 에러가 발생한다. 외부에서 Operato..