코틀린의 경우 여러 종류의 반복문이 있습니다. 이러한 반복문들은 2가지로 나눌 수 있습니다. for나 while 같은 예약어로 구성된 반복문과 repeat, foreach 같은 함수형 반복문이 있습니다. 오늘은 이 함수들을 알아보고 이반복문들의 비교를 해보도록 하겠습니다. 예약어 for for(i in Iterable){} 가장 기본적인 반복문입니다. 연속적인 값(Iterable)들을 순환하며 해당 값들을 i에 넣고 연속적인 값들의 크기만큼 순환합니다. while, do while while(조건){} do {} while(조건) 조건이 참일 경우에만 반복하는 반복문입니다. do while은 최소한번은 실행한다는 차이점이 있습니다. 함수형 반복문 repeat repeat(){} @kotlin.intern..
이 Effective Kotlin책으로 공부를 하면서 첫 장인 안정성 파트를 끝냈습니다. 이안정성 파트를 끝내고 느낀점은 지금까지 짰던 코드들은 그 당시에는 안전하다고 생각했지만 그렇게 안전한 코드는 아니었습니다. 코드를 안전하게 만들기 위해서는 기존에는 실행 시 돌아가기만 하면 된다고 생각했습니다. 지금 보면 우스운 일입니다. 눈으로 보기에는 잘 돌아가는 것처럼 보여도 잠재적인 오류가 지뢰처럼 깔려있을 것입니다. 만약 이러한 코드로 구성된 앱을 플레이스토어에 올린다고 생각하면 엄청난 컴플레인을 받을 것입니다. 이번장의 목표인 오류가 덜 발생하는 코드를 만들라는 것은 머리에 다가왔습니다. 안정성 파트를 공부하면서 가장 크게 다가온 부분은 가변성과 Failure였습니다. 이전까지는 빠른 코드를 작성하는 데..
안드로이드 스튜디오를 사용하다 보면 이런 화면을 본 적이 있을 겁니다. 이곳은 단위테스를 하는 공간입니다. 그렇다면 단위테스트는 또 무엇일까요? 이번 포스팅에서는 단위테스트 무엇인지 단위테스트를 왜 써야 하는지를 알아보도록 합시다. 단위 테스트(Unit Test)는뭐지? 단위 테스트는 일반적으로 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트입니다. 즉 기능들의 잘 동작하는지 확인하는 작업이라고 생각하면 됩니다. 안드로이드 스튜디오 환경에서는 프로젝트생성 시 단위테스트를 할 수 있는 공간들을 자동으로 만들어 줍니다. 이 공간에서 기능들이 잘 작동하는지 테스트를 할 수 있습니다. 또한 코틀린에서는 @Test라는 어노테이션을 이용하여 해당함수가 단위테스트용..
코틀린에서는 close메서드를 통해 명시적으로 닫아줘야 하는 리소스들이 있습니다. InputStream, OutputStream java.sql.Connection java.io.Reader java.new.Socket, java.util.Scanner 이러한 리소스들은 AutoCloseable을 상속받는 Closeable인터페이스를 구현하고 있습니다. 이러한 모든 리소스는 최종적으로 리소스에 대한 레퍼런스가 없어질 때 가비지 컬렉터가 처리해 주지만, 느리며 그동안 리소스 유지비용이 많이 들어갑니다. 그렇기 때문에 위에서 말한 데로 명시적으로 리소스를 닫아줘야 합니다. try { return reader.lineSequence().sumBy {it.lentgh} } finally { reader.clos..
알고리즘 문제들을 풀다 보면 해당 조합에 대해서 교집합 합집합 차집합들을 물어보는 문제가 많습니다. 코틀린은 이러한 요구들을 해결해 줄 수 있는 여러 함수들을 가지고 있습니다. 오늘은 그 함수들을 알아볼까 합니다. 합집합(union) public infix fun Iterable.union(other: Iterable): Set { val set = this.toMutableSet() set.addAll(other) return set } 이처럼 mutableSet을 이용하여 2가지 연속적인 객체의 값들을 모두 넣어 Set자료형으로 반환하는 함수입니다. 교집합(intersect) public infix fun Iterable.intersect(other: Iterable): Set { val set = ..
코틀린의 특징을 말하자면 코드를 nullable 하게 짤 수 있다는 점일 겁니다. 오늘을 그 null은 어떻게 처리하는 게 좋을까라는 주제로 말을 해볼까 합니다. null은 잘못사용하게 되면 어떻게 될까요? val printer: Printer? = getPrinter() printer.print() // 컴파일 오류 아래처럼 컴파일러 차원에서 오류가 나오기도 합니다. 또한 null이 아니라는 것을 확신을 하여!!(not- null assertion)을 사용하게 된다면 해당값이 null 이 아니라면 잘 써지겠지만 만약 이 printer가 null이라면 NPE(null point exception)가 생기고 맙니다. 그렇기 때문에 이번장에서는 null을 어떻게 처리해야 안전하게 처리할 수 있는지에 대해서 ..
이전포스팅에서 예상 못한 상황에서는 예외를 사용하라고 말하였습니다. 그렇지만 예외를 사용하는 것이 모든 상황에 알맞은 것은 아닙니다. 예외는 잘못된 특정된 상황에 사용해야 하지만 예를 들어 내트워크 문제나 텍스트 파싱시 텍스트 형식이 맞지 않은 경우 같이 함수가 원하는 결과를 만들어 낼 수없을 때에는 이러한 예외는 부적절할 수 있습니다. 많은 개발자가 예외를 전파되는 과정을 추적하지 못합니다. 코틀린의 모든 예외는 unchecked 예외입니다. 따라서 사용자가 예외를 처리하지 않을 수도 있으며, 이와 관련된 내용은 문서에도 제대로 드러나지 않습니다. 실제로 API를 사용할 때 예외와 관련된 사항을 단순하게 메서드등을 사용하면서 파악하기 힘듭니다. 예외는 예외적인 상황을 처리하기 위해서 만들어졌으므로 명시..
이전에 배운 require, check, assert 함수의 경우 넣어준 값이 참이 아니면 IllegalArgumentException이나 IllegalStateException, AssertionError 같은 예외들을 throw 해줍니다. 또한 코틀린에서는 사용자정의 Exception을 만들어 이러한 Exception들을 throw 해줄 수 있습니다. 그렇지만 이 책에서는 사용자정의 Exception을 만들어 사용하는 행동보다는 표준라이브러리의 예외들을 사용하기를 권하고 있습니다. 그 이유들로는 협업하는 팀원들이나 다른 사람들이 보더라도 표준라이브러리 예외들로 더 잘 이해할 수 있게 될 것입니다. 그런 김에 추가로 코틀린에서 자주보이는 예외들을 봐볼까 합니다. llegalArgumentExceptio..
해당과정은 계산기 코드를 짜면서 단일 책임 원칙과 의존성 역전 원칙을 적용시켜 가면서 얻은 고찰입니다. 기존 코드를 짰을 때는 돌아기만 하면 된다는 생각으로 코드를 작성하였습니다. 기본적인 기능 구현 Calculator.kt class Calculator { private val keys = setOf( Key.CALCULATE_STOP, Key.CALCULATE_ADD, Key.CALCULATE_MINUS, Key.CALCULATE_MULTIPLY, Key.CALCULATE_DEVIDE, ) fun calculate() { println("계산을 진행하겠습니다.") println( "계산의 종류\n" + "------------------------------------------------------..
🚫예외를 활용해 코드에 제한을 걸어라.. 이번 안정성 챕터에서는 이전에서도 보았듯이 예상치 못한 동작을 막고 앱의 안정성을 높이는 방법을 코드에 여러 제한을 걸어 앱이 예상치 못한 동작을 하지 못하도록 막는 방법과 이렇게 막을 경우 얻는 여러 장점들에 대해서 얘기합니다. 방법 1. 아규먼트(argument) require 블록: 아규먼트에 제한할 수 있음 require함수 같은 경우 값이 참인지 체크하고 거짓일 경우 IllegalArgumentException을 throw 시킵니다. 이와 비슷하게 requireNotNull함수가 존재하는데 값이 Null일 경우 IllegalArgumentException을 throw 시킵니다. public inline fun require(value: Boolean): ..
