본문 바로가기

kotlin29

[kotlin] 코틀린 차곡차곡 - 18. value class (inline class) 안녕하세요. 오늘은 오랫만에 코틀린 알아보는 포스팅으로 찾아왔습니다. 오늘 여러분들에게 소개해드릴 코틀린 개념은 value class입니다. 자 그럼 바로 들어가보도록 하겠습니다. 상황 설명 유저 정보를 담는 Entity를 만들어보도록 하겠습니다. email, hashedPassword, displayName, createdAt 필드를 가지도록합니다. 그리고 email은 email의 특정 형식이 있습니다. 하지만 User Entity에서는 String 형식으로 email을 받고 있기때문에 email 형식을 충족시키지 못하더라도 Entity 생성을 할 수 있습니다. 이러한 검증을 위해서 init을 이용할 수 있습니다. 그리고 email의 경우 domain과 id를 @ 기준으로 분리할 수 있기 때문에 해당 .. 2023. 2. 4.
CQRS(Command and Query Responsibility Segregation) 맛보기 - 실습편 안녕하세요. 이전 포스팅에서 우리는 CQRS는 어떤것이고 어떤 장점과 단점을 가지고 있는지 함께 보는 시간을 가져보았습니다. 오늘은 CQRS를 한번 실습해보는 시간을 가져보도록 하겠습니다. 이전 시간에 CQRS를 설명할 때 두가지 모델뿐만 아니라 CQRS를 지속적으로 이어주기 위한 사이드적인 매커니즘들이 필요하다고 말씀드렸었습니다. 그러한 부분을 함께 보도록 하겠습니다. 1편 : CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편 환경 오늘 포스팅에서 사용할 환경은 아래와 같습니다. write DB의 DataSource는 MongoDB를 이용합니다. 그리고 Read 모델의 Repository는 Redis 라고 명시해 두었지만 실습이기 때문에 빠른 .. 2022. 6. 25.
[kotlin] 코틀린 차곡차곡 - 17. require와 check 안녕하세요. 오늘은 오랫만에 코틀린 차곡차곡 시리즈로 찾아왔습니다. 오늘 여러분들께 공유 드릴 내용은 코틀린에서 validation에 대해서 이미 정해져 있는 코드들에 대한 내용입니다. 기존의 validation asis 메서드를 원하는 바로 정확하게 실행시키기 위해서는 실제 본연의 메서드 로직을 실행시키기전에 validation으로 input으로 들어오는 파라미터의 값이나 사용하는 상태 적절한지에 대한 판단이 필요합니다. 이러한 validation은 보통 아래의 2가지로 나눌 수 있습니다. 파라미터 값 자체에 대한 validation 파라미터 값에 의한 기존 Entity를 비롯한 도메인이 가지고 있는 상태에 대한 validation 이러한 valitaion을 구현한다고 하면 기존에는 아래의 코드처럼 일.. 2022. 6. 5.
[kotlin] 레거시(legacy) 코드 리팩토링하기 3편 - 리팩토링 진행하기 1편 : 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 2편 : 레거시(legacy) 코드 리팩토링하기 2편 - 리팩토링 진행하기 안녕하세요. 레거시를 리팩토링하는 3번째 시간입니다. 오늘은 이전 포스팅에서 만들어둔 라인커버리지 100%의 테스트코드에 대한 신뢰를 바탕으로 코드가 좋은 가독성을 가지는 방향으로 리펙토링을 실제로 진행해보고자 합니다. 환경 환경은 이전 시간과 마찬가지로 아래와 같습니다. 기본적인 테스트 프레임워크는 JUnit5를 사용하며 mockking을 위해서 Unit 테스트 라이브러리인 mockk를 추가로 사용합니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-t.. 2022. 5. 16.
[kotlin] 레거시(legacy) 코드 리팩토링하기 2편 - 라인커버리지 100% 달성하기 안녕하세요. 오늘은 [kotlin] 레거시(legacy) 코드 리팩토링하기 1편에 이어서 테스트를 통해 실제로 라인커버리지를 100% 달성해보는 포스팅을 진행해보고자 합니다. 이전 편은 테스트 코드를 작성해야 하는 이유에 대해서 설명했습니다. 관심있으신 분들은 한번 보시는것을 추천드립니다. 환경 이번 포스팅과 다음 포스팅에 진행되는 test 환경에는 JUnit5와 코틀린 mock에 주로 사용하는 mockk 라이브러리를 이용하였습니다. build.gradle.kts의 implementation는 아래와 같이 선언하였습니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-test") { exclude(group = "or.. 2022. 4. 23.
[kotlin] 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 안녕하세요. 서비스의 시간이 오래되면 레거시 코드에 대해 고민이 생기기 마련입니다. 특히 이제는 퇴사한 사람이 남기고간 장황하고 이유를 알 수 없는 코드에 수정이 필요하게 되면 덜컥 겁이나기 시작합니다. 그런 코드들은 생성된 시간이 오래되면 오래될수록 공포감도 커지고 건들고 싶지 않아집니다. 하지만 그렇다고 수정을 안할수도 없습니다. 무작정 수정하게되면 실수 등에 의해서 잘 되던게 오히려 잘못 동작할수도 있습니다. 때문에 우리는 수정하기에 앞서 어느정도 안전장치를 만들어둘 필요가 있습니다. 그것이 바로 테스트 코드를 작성하는 것입니다. 오늘은 레거시 코드에 테스트 코드를 작성하고 커버리지를 올리는 방법에 대해서 알아보는 시간을 가져보도록 하겠습니다. 레거시 코드에 유닛 테스트 코드를 추가하면서 얻을 수 .. 2022. 4. 16.
[kotlin] 코틀린 차곡차곡 - 16. kotlin JVM annotation 알아보기 2편 안녕하세요. 오늘은 이전 시간에 이어서 JVM annotation에 대해서 알아보는 시간을 가져보도록 하겠습니다. 오늘 알아볼 코틀린의 JVM annotation은 이전시간에 알아보지못한 @JvmOverloads, @JvmDefault, @Throws, @JvmWildcards 등입니다. @JvmOverloads 코틀린과 자바는 100% 호환 된다고 합니다. 하지만 몇몇 부분에 있어서는 상호 호환이 되지 않는 부분이 있습니다. 그 중 대표적인 하나가 코틀린의 default 값에 대해서 자바에서 호출하지 못한다는 것입니다. 아래 예제 코드를 한번 보면서 좀 더 들여다 보도록 하겠습니다. 코틀린의 함수를 아래처럼 선언하면 이는 아래의 3가지 방법으로 모두 접근이 가능합니다. 코틀린에서 default 파라미터.. 2022. 1. 26.
[kotlin] 코틀린 차곡차곡 - 15. kotlin JVM annotation 알아보기 안녕하세요. 오늘은 kotlin JVM annotation에 대해서 알아보는 시간을 가져보도록 하겠습니다. JVM annotation 코틀린은 컴파일 시 자바 바이트코드(.class)로 변환 되어지게 되며 다른 자바 파일들과 상호호환 되게 되고 JVM에 의해서 실행되게 되는 과정을 거칩니다. 이러한 과정 중 코틀린 파일에서 자바 바이트코드로 변경될 때좀 더 정밀한 제어를 할 수 있도록 하는 kotlin annotation이 있습니다. 이러한 어노테이션을 JVM annotation이라고 합니다. 이러한 JVM annotation의 종류는 아래와 같으며 오늘은 하나씩 차근차근 알아보는 시간을 가져보도록 하겠습니다. @JvmName @JvmStatic @JvmField @JvmDefault @JvmOverlo.. 2022. 1. 22.
[gradle] buildSrc를 이용한 gradle 의존성 관리 안녕하세요. 오늘은 gradle의 의존성 관리를 좀 더 명확하고 유지관리하게 쉽게 할 수 있는 gradle의 buildSrc에 대해서 알아보는 시간을 가져보도록 하겠습니다. 빌드 도구의 상수와 함수 코딩을 하면 기본적으로 자주 사용하는 함수 또는 상수에 대해서 별도의 파일로 선언하여 여러 곳에서 참조할 수 있게합니다. 이렇게 함으로써 중복 코드를 줄이고 코드의 가독성도 높일 수 있습니다. 이건 이 글을 읽고 있는 개발자이신 여러분들에게는 기본적인 것이겠지요. gradle 에서도 buildSrc를 이용하면 이러한 방법으로 script를 작성할 수 있다는 사실을 알고 있으셨나요 ? buildSrc를 이용하면 build script를 더 쉽게 유지보수하고 가독성을 향상시킬 수 있습니다. buildSrc와 in.. 2021. 11. 22.
[kotlin] kotlin 1.4.0 RELEASE 정리 안녕하세요. 오늘은 kotlin 1.4.0 버전 RELEASE에 업데이트 된 내용을 한번 살펴보도록하겠습니다. kotlin 1.4.0 코틀린 1.4.0은 성능과 품질에 집중했다고 합니다. 어떤 점이 변경되었는지 아래에서 바로 알아보겠습니다. kotlin/JVM 기준으로 알아두면 좋을것 같은 것들만 발췌하였습니다. 코틀린 Interface SAM(Single Abstract Method) Java8부터 Interface에 1개의 메서드만 가지게 되면 이를 함수형 인터페이스(Functional Interface)라고 부르며 람다(lambda)식으로 사용할 수 있게됩니다. 이를 SAM(Single Abstract Method)라고도 부릅니다. 대표적으로 Function이라는 인터페이스가 있습니다. @Funct.. 2021. 11. 11.
[kotlin] 1.3 버전 RELEASE 정리 안녕하세요. 최근 회사의 업무를 하던 중 필요에 의해서 kotlin 버전이 올라가면서 추가된 것을 확인해 볼 필요가 있었습니다. 정리한 내용을 이대로 버리기에는 아깝다고 생각했습니다. 오늘은 kotlin 1.3의 RELEASE에 대해서 번역한 내용을 공유드립니다. Kotlin 1.3.x kotlin 1.3.x 버전은 최초에 2018년에 출시된 코틀린 버전입니다. pre 버전을 제외한 최초 RELEASE은 1.3.0 버전으며 2018년 10월에 나왔으며 최종버전은 1.3.72로 2020년 4월에 출시되었습니다. 최초버전만 보자면 오래된 버전이긴합니다. 그러면서 최종 버전이 2020년 4월이기 현재.. 1.6.x 버전을 preview 하고 있기때문에 나름 장기간 유지된 메이저 버전이란 것도 알 수 있습니다... 2021. 11. 7.
[kotlin] 코틀린 차곡차곡 - 14. 중위 표기법 함수 (infix notation function) 안녕하세요. 오늘은 코틀린에 대해서 알아보는 14번째 시간입니다. 오늘은 여러분과 infix function에 대해서 알아보는 시간을 가져보도록 하겠습니다. infix function 이란 infix function은 어떤걸까요? 먼저 infix function에 대해서 알아보기 전에 infix 라는 단어가 어색하실 수 있을것 같습니다. 그렇다면 preifx, postifx는 좀 익숙하실까요? prefix는 앞에 어떤 행위가 온다는 것이고 postfix는 뒤에 어떤 행위가 온다는 것입니다. 간단한 예를 들어보면 표기법(expression)을 들 수 있을것 같습니다. 표기법은 연산자를 어디에 두냐에 따라 전위(prefix), 후위(postfix), 그리고 중위(infix)로 나뉘게 됩니다. 즉, infix.. 2021. 10. 23.