일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- ruby
- hugo 로 블로그
- kotlin
- Convariance
- 코틀린
- 코틀린 in
- 객체지향
- IntelliJ
- 개인블로그 hugo
- 코틀린 out
- 코틀린 노트북
- standard output
- 돌연변이 테스팅
- output stream
- cli 만들기
- InnoDB
- Mutation testing
- image resizer with go
- Test
- 공짜블로그
- 자바
- resize image with go
- JPA
- 의존성역전원칙
- Pitest
- MySQL
- Java
- change refresh rate
- standard input
- resizer 구현
- Today
- Total
목록Kotlin (48)
Rlog
가변성을 제한해라 들어가기에 앞서 이건 완전한 번역글이 아닙니다. 원서를 읽고 느낀점을 적은 글 입니다. 본문 일단 첫장 부터 가변성을 제한하라고 적혀있다. 책에서 나온 글귀중 이런 글이 있다. When an element holds state, the way it behaves depends not only on how you use it, but also on its history 나는 이뜻을 이렇게 해석했는데 element 가 상태를 지니고 있을때 상태를 다루는 방법은 오직 어떻게 사용하는 것에만 의존하는 것이 아니라 그것의 History(객체의 변화 상태를 보여주는 것이라고 나는 해석했다) 에도 관련있다. 그래서 아래 예시가 나오는데 같이 한번보자. class BankAccount { var ba..
이번에 새로 진행하는 신규 프로젝트를 작업중이였는데 모니터링을 하던 도중 의도치 않게 MinorGC 가 자주 발생하고, 시간 또한 긴것을 발견하였다. 그래서 이를 어떻게 개선했는지 그 방법에 대해서 적어보려고 한다. 탐색 일단 Spring Application Proccess 의 번호를 알아야 한다. jps 프로세스를 알았다면 현재 HeapDump 를 떠서 확인해야 한다. (내 프로세스 번호는 6485번 이였다.) jmap -dump:format=b,file=heapdump.hprof 6485 잘 dump 가 떠졌다면 아래와 같이 heapdump.hprof 라는 파일을 확인할 수 있을 것이다. 이 파일을 열기 위해서 GC 를 Monitoring 할 수 있는 도구인 VisualVM 을 이용했다. Dump ..
Delegation 은 코틀린에서 지원하는 문법적 기능 중 하나인데, 이는 Delegation Pattern 의 Boiler Plate 를 줄여주는 Sugar Syntex 중 하나이다. Delegation Pattern 은 쉽게 말해 상속이 아닌 다른 객체에게 세부 구현을 위임하는 것이다. 공식문서의 예제를 한번 살펴보자. interface Base { fun print() } class BaseImpl(val x: Int) : Base { override fun print() { print(x) } } class Derived(b: Base) : Base by b fun main() { val b = BaseImpl(4) Derived(b).print() } 위의 예제는 Derived 의 내부 인터페이..
오늘 Kotlin 을 사용하다가 objcet 로 만든 곳에서 Class 내부 Property 를 참조해야 하는 일이 생겼다. 코드는 대략적으로 아래와 비슷한 상황이였다. interface Roach { fun roa() } class Test( val testProperty: String, ) { fun test() { object : Roach { override fun roa() { // testProperty 에 접근하고 싶음 } } } } 처음에는 음 this 를 사용하면 붙어질까? 라는 생각을 했지만 당연히도 익명 클래스의 안이기 때문에 오히려 this 에 맵핑되어 있는 객체는 익명 클래스의 인스턴스 라는 것을 깨닫게 됬다. 그래서 어떻게 할까 하다가 아래와 같은 방법이 되는지도 테스트 해봤다...
코틀린에서 가끔씩 고차함수에서 Return 을 할 경우에 안되는 경우가 있다. 바로 아래 코드와 같은 상황일 경우에 말이다. fun forEach(a: IntArray, action: (Int) -> Unit) { for (n in a) action(n) } fun main() { forEach( intArrayOf(1, 2, 3, 4)) { if (it 3) return println(it) } ) } 이 이유는 무엇일까? 이건 일단 람다 안에서의 return 에 대해서 생각해봐야 하는데, 일단 lambda 안에서의 return 은 가까운 함수 혹은 무언가 람다를 둘러싸고 있는 환경을 반환하려고 시도한다. 즉 위의 코드에서는 return 이라는 함수가 main() 함수를 반환하려고..
코틀린이란 언어는 상당히 문법적으로 코드를 간결하게 작성할 수 있는 기능을 많이 제공한다. "중위 연산자", "확장 함수", "람다구문의 it" 등 을 지원하고 있다. 우리는 이러한 방법을 이용해 좀 더 간결하게 코드를 작성할 수 있다. 예를 들면 아래와 같이 말이다. 1.to("one") 1 to "one" 확장함수를 이용하면 아래처럼 조금 더 객체지향 적인 코드를 짤 수 있다고 생각한다. StringUtil.capitalize(s) // java s.capitalize() // kotlin 내부 DSL 또한 코틀린에서는 좀 더 가독성 좋은 코드를 작성할 수 있도록 내부 DSL 또한 지원한다. 여기서 짚고 넘어가야 할 점이 있는데 DSL 에 대해서 조금 알아보자. 우리가 보통 잘 알고 있는 DSL 은 ..
사실 우리가 특정 클래스를 이용하다보면 자신이 수동으로 생성한 Mapper 혹은 라이브러리로 만들어진 Mapper 를 통해서 해당 클래스를 변환해야 하는 일이 생길 수 있다. 근데 나는 이런 Mapper 를 쓰는게 좋은 코딩이지는 잘 모르겠다. 너무 번잡하게 만드는 것이 아닌가? 라는 생각이 든다. 그래서 공통모듈 Mapper 를 쓰는걸 좋아하지 않는다. 코드로 설명하면 대략적으로 아래와 같다. Integer a = 10; String b = StringMapper.from(a); System.out.println(b) // "10" 위의 코드가 Mapper 를 쓰는 예시인데 나는 이게 객체지향스러운가 라는 의문도 있긴하다. 사실 대부분 위처럼 쓰는 사람은 많지 않을테고, 아래처럼 쓰는 경우가 훨씬 많다..
코틀린 하면서 처음에는 잘 이해하지 못했던 DSL 문법의 간결함을 알게 되면서 infix 로 연계하여 만들 수 있는 DSL 구조가 좋은 것 같다는 생각이 들었다. 예를 들면 원래 Java + QueryDSL 을 사용한다면 아래와 같은 코드가 작성될 수 있을 것이다. selectFrom(person).where(person.name.eq("roach)) 하지만 코틀린의 infix 를 이용한다면 다르게 풀어볼 수도 있을 것이다. selectFrom person where person.name is "roach" 내 생각엔 Kotlin 에서 QueryDSL 을 쓰는건 계속해서 JPA + QueryDSL 을 써왔기때문이라고 생각하는데 Kotlin + Spring + JPA 를 이용한다면 QueryDSL 보다 i..