연산자 오버로드는 의미에 맞게 사용해야 합니다. 코틀린은 객체의 연산자 기능을 함수로 오버로드할 수 있습니다. 이 기능은 아주 강력한 기능이지만 잘못 사용할 경우 가독성 문제뿐만 아니라 큰 위험으로 다가올수도 있습니다. 팩토리얼 함수를 예를 들어 봅시다. 수학에서는 팩토리얼 함수를 A!로 표현합니다. 그렇지만 대부분의 코드에서는 저런 팩토리얼 같은 기능을 연산자로 재공하고 있지는 않습니다. fun Int.factorial(): Int = (1..this).product() fun Iterable.product(): Int = fold(1) { acc, i -> acc * i } 대부분 이런 식으로 로직을 작성해야 합니다. print(10 * 6.facorial()) // 10 * (6!) = 7200 /..
코트는 작성할 때보다 수정할 때 더 많은 시간을 필요로 합니다. 그 이유는 해당 코드를 일고 이해하며 어디를 수정해야 하는지 찾아야 하기 때문입니다. 그렇기에 보았을 더 쉽게 이해할 수 있는 코드를 짜는 것은 중요합니다. 이번장이 가독성에서는 어떻게 해야 잘 읽히고 좀 더 이해하기 쉬운지를 주제로 이야기를 해나갈까 합니다. 코틀린은 코드를 간결한게 만들어주는 예약어와 여러 함수들을 가지고 있습니다. 이러한 부분은 코드를 간결하게 짜는 것을 도움을 주지만 어떻게 보면 가독성이 떨어지는 코드를 짜는 것도 도와줍니다. 예를 들어 일반적인 if 같은 조건문을 쓰는 코드가 있다고 생각해 봅시다 이러한 조건문은 코드 짜는 사람들에게 있어서 코틀린을 배우지 않고 다른 언어들을 배운 사람들이더라도 이러한 조건문은 더 ..
이 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..
코틀린의 특징을 말하자면 코드를 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..
🚫예외를 활용해 코드에 제한을 걸어라.. 이번 안정성 챕터에서는 이전에서도 보았듯이 예상치 못한 동작을 막고 앱의 안정성을 높이는 방법을 코드에 여러 제한을 걸어 앱이 예상치 못한 동작을 하지 못하도록 막는 방법과 이렇게 막을 경우 얻는 여러 장점들에 대해서 얘기합니다. 방법 1. 아규먼트(argument) require 블록: 아규먼트에 제한할 수 있음 require함수 같은 경우 값이 참인지 체크하고 거짓일 경우 IllegalArgumentException을 throw 시킵니다. 이와 비슷하게 requireNotNull함수가 존재하는데 값이 Null일 경우 IllegalArgumentException을 throw 시킵니다. public inline fun require(value: Boolean): ..
책에서는 타입추론(type interference)으로 리턴하지 말라합니다. 잠시 타입추론을 설명하자면.. val name = "John" // 변수 name은 String 타입으로 추론됨 val age = 25 // 변수 age는 Int 타입으로 추론됨 fun calculateSum(a: Int, b: Int): Int { return a + b } val result = calculateSum(5, 10) // 변수 result는 Int 타입으로 추론됨 위 코드처럼 코틀린은 타입을 지정하지 않아도 위의 코드처럼 처음 초기화될 때의 값에 따라 타입추론 하여 해당 변수나 상수의 타입을 지정해 줍니다. 이러다 보니 해당값에 착가하고 다른 것을 넣게 될 경우 당연히 Type mismatch오류가 발생합니다...
