4. Java 대체를 위한 코틀린의 요구사항
• 정적타입 지정 언어
• 기존 자바 코드와 100% 호환성
• 쉬운 도구-지원 개발
• 배우기 쉽고 뜻을 파악하기 쉬운 언어
현재 자바가 사용되고 있는 모든 용도에 적합하면서도
더 간결하고 생산적이며 안전한 대체 언어를 제공하는 것
5. 코틀린의 철학
실용성
• 이미 성공적으로 검증된 해범과 기능에 의존
• 특정 프로그래밍 스타일이나 패러다임을 사용할 것을 강제하지 않음
• 편리한 개발 환경과 도구의 활용을 염두하여 설계
간결성
• 의미가 없는 코드와 요소를 줄이기 위해 많은 노력
안전성
• JVM에 기반한 안전성 보장
• Nullable 타입 추적과 타입추론을 통한 NPE, ClassCastException 외 기타 런타임오류 최소화
상호운용성
• 기존 자바 기반 라이브러리를 그대로 사용가능.
• 기존 프로젝트에서 자바와 코틀린 모두 사용 가능
6. 정적타입 지정 언어란?
컴파일 시 변수의 ‘타입’이 결정되는 언어.
👍 장점
• 높은 타입 안정성
• 타입 관련 런타임 오류 방지가능
• 컴파일 시에 미리 타입이 결정되어 실행 속도가 빠름
• 코드의 가독성이 좋음
• 장기 개발 및 유지보수에 유리함
😒 단점
• 매번 타입을 결정해줘야 하는 번거로움 존재
7. 함수 – Hello World!
함수는 fun키워드로 정의하며 기본적으로 public
void나 타입추론이 가능한 경우 반환타입을 생략 가능
8. 함수 – 블록({})과 식(Expression)
코틀린에서 블록이 본문인 함수와 식이 본문인 함수 두가지 구분
식이 본문인 함수의 반환 타입은 타입 추론을 통해 결정
10. 변수
val(=value): 변경 불가능한 참조
var(variable): 변경 가능한 참조
타입추론에 의해 타입을 생략할 수 있지만, 한번 지정된 타입은 고정
가능한 val키워드를 사용하는 것을 권장
11. 타입 – Nullable 타입
Null 문제를 실행 시점 -> 컴파일 시점으로 옮겨 NPE 가능성 최소화
Type? = Type 또는 null
Type = Type
nullable타입과 non-null 두 타입으로 구분
Java와 달리, non-null타입에는 nullable타입을 할당 불가능
우리가 자바를 대신할 언어에 대해 어떤 요구 사항을 갖고 있었을까?
정적 타입 지정 외에 수백만 줄이나 되는 코드 베이스를 미치지 않고 개발할 수 있는 다른 방법은 없다. 둘째로 기존 자바 코드와 완전히 호환되는 언어가 필요했다. 기존 코드베이스는 젯브레인스의 엄청나게 귀중한 자산이며, 상호운용성이 부족해서 그런 자산을 잃어버리거나 자산의 가치가 줄어 드는 일을 용납할 수는 없었다. 셋째로 그 언어를 위한 도구 개발이 쉬워야만 했다. 우리는 도구 제공 가능성을 타협하고 싶지 않았다. 회사로서 젯브레인스에 가장 중요한 가치는 개발 생산성이며, 높은 생산성을 얻기 위해서는 훌륭한 도구가 필수다. 마지막으 로 배우기 쉽고 뜻을 파악하기 쉬운 언어가 필요했다.
자바의 개념과 기법 위에 만들어진 코틀린의 주목적은 현재 자바가 사용되고 있는 모든 용도에 적합하면서도 더 간결하고 생산적이며 안전한 대체 언어를 제공하는 것이다.
실용성
코틀린은 실제 문제를 해결하기 위해 만들어진 실용적인 언어다.
코틀린은 실험적인 기능을 추가하지 않고, 다른 프로그래밍 언어가 채택한 이미 성공적으로 검증된 해범과 기능에 의존하다.
코드가 더 간결할수록 내용을 파악하기가 더 쉽다.
기존 자바의 번거로운 준비 코드를 묵시적으로 제공하여 지저분해지는 일을 줄였다.
코틀린을 JVM에서 실행한다는 사실은 이미 상당한 안전성을 보장할 수 있다는 뜻이다. 메모리 안전성을 보장하고, 버퍼 오버플로를 방지하며, 동적으로 할당한 메모리를 잘못 사용함으로 인해 발생할 수 있는 다양한 문제를 예방하고 타입 안전성을 보장한다. 코틀린을 만들면서 자바보다 더 높은 수준의 안전성을 달성하되 전체 비용은 더 적게 지불하고 싶었다. 대부분의 경우 코틀린 컴파일러가 타입을 자동으로 추론해준다. 보다 간편한 방법으로 실행시점에 오류를 더 많이 방지해준다. 코틀린의 타입 시스템은 오직 ? 한글자만 추가하는 것으로 null이 될 수 없는 값을 추적하며 NPE가 발생할 수 있는 연산을 사용하는 코드를 금지한다. val s: String?= null -> 널이 될 수 있음. val s2: String = "" -> 널이 될 수 없음 코틀린에서는 타입 검사와 캐스트가 한 연산자 is 에 의해 이뤄진다. 타입 검사를 생략할 이유가 없고, 그로인해 ClassCastException 오류가 발생할 일도 없다.
상호운용성
기존 자바 지반 라이브러리를 그대로 사용할 수 있다.
코틀린은 기존 자바 라이브러리를 가능하면 최대한 활용한다.
예를 들어 코틀린 자체 컬렉션 라이브러리를 제공하지 않고 자바 표준 라이브러리 클래스에 의존한다. 다만 코틀린에서 컬렉션을 더 쉽게 활용할 수 있는 몇 가지 기능을 더할 뿐이다.
코틀린이 제공하는 도구도 다운 언저 프로젝트를 완전히 지원한다. 코틀린은 자바와 코틀린 소스 파일이 임의로 섞여 있어도 제대로 프로그램을 컴파일할 수 있다.
정적타입 언어는 컴파일 시 변수의 ‘타입’이 결정, 동적타입 언어는 런타임 시 변수의 ‘타입’이 결정됩니다.
👍 정적타입 언어의 장점
타입 에러로 인한 문제점을 초기에 발견할 수 있어 타입 관련한 런타임 오류를 방지할 수 있고 타입의 안정성이 높음.
특히, 사용자에게 배포되는 앱의 경우 타입 관련한 검증을 컴파일 시에 하지 않고 런타임에 하게 되면 앱 사용 시 타입 불일치로 인한 크래시의 발생 위험이 높아짐.
컴파일 시에 미리 타입을 결정하기 때문에 실행 속도가 빠름
코드의 가독성이 좋음. 다수의 협업이나 프로젝트의 장기 개발 및 유지보수에 유리함.
😒 정적타입 언어의 단점
매번 코드 작성시 변수형을 결정해줘야 하는 번거로움이 있음.
👍 동적타입 언어의 장점
런타임까지 타입에 대한 결정을 끌고 갈 수 있기 때문에 유연성이 높음
타입 관련하여 지켜야 할 규칙이 적기 때문에 상대적으로 코드가 짧고 Learning-Curve가 낮다.
😒 동적타입 언어의 단점
실행 도중에 변수에 예상치 못한 자료형이 들어와 TypeError를 발생할 수 있음.
타입 관련 Error는 런타임 시 확인할 수 밖에 없기 때문에, 코드가 길고 복잡해질 경우 타입 에러를 찾기가 어려워짐.
이러한 불편함을 해소하기 위해 TypeScript나 Flow 등을 사용할 수 있음.
식이 본문인 함수와 블록이 본문인 함수로 나뉜다. *코틀린의 if는 문장(statement)이 아니고 식(expression)이다.
식이 본문인 함수와 블록이 본문인 함수로 나뉜다. *코틀린의 if는 문장(statement)이 아니고 식(expression)이다.
코틀린은 null 문제를 실행 시점에서 컴파일 시점으로 옮겼다.
null여부를 컴파일 시 미리 감지해서 실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있다.
타입 이름 뒤에 ?를 붙이면 null참조를 붙일 수 있다.
Nullable 타입은
널체크를 하지 않으면 변수.메소드()처럼 메소드를 직접 호출할 수는 없다.
2. non-nullable 타입 변수에 대입할 수 없다.
코틀린은 null 문제를 실행 시점에서 컴파일 시점으로 옮겼다.
null여부를 컴파일 시 미리 감지해서 실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있다.
타입 이름 뒤에 ?를 붙이면 null참조를 붙일 수 있다.
Nullable 타입은
널체크를 하지 않으면 변수.메소드()처럼 메소드를 직접 호출할 수는 없다.
2. non-nullable 타입 변수에 대입할 수 없다.
코틀린은 null 문제를 실행 시점에서 컴파일 시점으로 옮겼다.
null여부를 컴파일 시 미리 감지해서 실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있다.
타입 이름 뒤에 ?를 붙이면 null참조를 붙일 수 있다.
Nullable 타입은
널체크를 하지 않으면 변수.메소드()처럼 메소드를 직접 호출할 수는 없다.
2. non-nullable 타입 변수에 대입할 수 없다.
코틀린은 null 문제를 실행 시점에서 컴파일 시점으로 옮겼다.
null여부를 컴파일 시 미리 감지해서 실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있다.Nullable 타입은
널체크를 하지 않으면 변수.메소드()처럼 메소드를 직접 호출할 수는 없다.
2. non-nullable 타입 변수에 대입할 수 없다.
코틀린은 null 문제를 실행 시점에서 컴파일 시점으로 옮겼다.
null여부를 컴파일 시 미리 감지해서 실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있다.Nullable 타입은
널체크를 하지 않으면 변수.메소드()처럼 메소드를 직접 호출할 수는 없다.
2. non-nullable 타입 변수에 대입할 수 없다.
자바에서 타입 캐스팅을 할 때, instanceof 연산자를 종종 생략하곤 한다.
Instanceof 연산자로 타입체크를 하지 않으면 ClassCastException이 발생할 가능성이 있다.
코틀린에서는 as? 연산자를 통해서 null-safe하면서 쉽게 타입 캐스팅을 할 수 있어 예외 발생 가능성이 낮아졌다.
자바에서는 타입 검사 수행 후, 명시적으로 타입 캐스팅을 해주어야 했지만
자바는 메서드 인자에 디폴트 값을 지원하지 않아서 다음와 같이 여러 메서드를 오버로딩하여 정의해야만 했습니다.
코틀린은 디폴트 값을 지원하기 때문에 불필요한 코드가 줄고, 가독성이 확실히 많이 개선되었습니다.
식이 본문인 함수와 블록이 본문인 함수로 나뉜다. *코틀린의 if는 문장(statement)이 아니고 식(expression)이다.
식이 본문인 함수와 블록이 본문인 함수로 나뉜다. *코틀린의 if는 문장(statement)이 아니고 식(expression)이다.