코틀린 철학

실용성

코틀린은 실제 문제를 해결하기 위해 만들어진 실용적인 언어이다.

• 코틀린은 다른 프로그래밍 언어가 채택한 이미 성공적으로 검증된 해법과 기능에 의존한다.(언어의 복잡도가 줄고, 더 쉽게 배울 수 있다)
• 특정 프로그래밍 스타일이나 패러다임을 사용할 것을 강요하지 않는다.
• 도구를 강조한다.
  • 좋은 언어만큼이나 편리한 개발환경도 생성성향상에 필수적이다.
  • 코틀린의 경우 intelliJ 아이디어의 개발과 컴파일러의 개발이 맞물려 이뤄져 왔다 

간결성

개발자가 코드를 새로 작성하는 시간보다 기존 코드를 읽는 시간이 더 길다. 

코드가 더 간단하고 간결할수록 내용을 파악하기 쉽다.

• 코틀린은 의도를 쉽게 파악할 수 있는 구문구조를 제공하고, 그 의도를 달성하는 방법을 이해할 때 방해가 될 수 있는 부가적인 준비 코드가 적다.
• 코틀린은 프로그램에 꼭 넣어야하는 부수적인 요소를 줄이기 위해 많은 노력을 했다.
• 자바에 존재하는 여러 부수적인 요소(게터, 세터, 생성자 파라미터)를 코틀린에서 묵시적으로 제공하기 때문에 간결하다.
• 또한 컬렉션을 원소를 찾는 것과 같이 일반적인 작업을 수행하기 위해 명시적으로 작성해야만 하는 코드를 코틀린에서는 람다를 지원하기 때문에 작은 코드 블록을 라이브러리 함수에 쉽게 전달할 수 있다.
  • 일반적인 기능을 라이브러리 안에 캡슐화하고 작업에 따라 달라져야 하는 개별적인 내용을 사용자가 작성한 코드 안에 남겨둘 수 있다.

안정성

프로그램에서 발생할 수 있는 오류중에서 일부 유형의 오류를 프로그램 설계가 원칙적으로 방지해 준다.

오류를 방지하는 데에는 대가가 따르기 마련인데, 컴파일러에게 프로그램이 어떻게 작동해야 하는지에 대한 정보를 더 자세히 제공해야만 컴파일러가 프로그램 코드와 작동 의도에 대한 정보가 일치하는지를 검증할 수 있다.

따라서 더 큰 안정성을 얻기위해서는 프로그램에 많은 정보를 덧 붙여야 하므로 생성성이 하락하는 것을 감수해야 하며, 서로 간의 트레이드오프 관계가 성립한다.

• 코틀린은 자바보다 더 적은 비용으로 타입 안정성을 사용할 수 있다.
  • 대부분의 경우 코틀린 컴파일러가 타입을 자동으로 추론해 주기 때문
• 실행 시점에 오류를 발생하는 대신 컴파일 시점 검사를 통해 오류를 더 많이 방지해준다.
  • NullPointerException을 없애기 위해 노력한다.
  • null이 될수 없는 값을 추적하며 실행 시점에 NullPointerException이 발생할 수 있는 연산을 사용하는 코드를 금지한다.
  • ? 한글자만 표시해 null이 될 수 있는지 여부를 표시
• ClassCastException을 방지해 준다.
  • 어떤 객체를 다른 타입으로 캐스트하기 전에 타입을 미리 검사하지 않을 경우 ClassCastException이 발생할 수 있다.
  • 코틀린에서는 타입 검사와 캐스트가 한 연산자에 의해 이뤄진다.
  • 어떤 객체의 타입을 검사했고 그 객체가 그 타입에 속한다면 해당 타입의 메서드나 필드 등의 멤버를 별도의 캐스트 없이 사용할 수 있다
  • 따라서 타입 검사를 생략할 이유가 없고, 검사를 생략하지 않으면 검사를 생략해서 생기는 오류가 발생할 일도 없다.

상호운용성

코틀린에서의 자바 기존 라이브러리를 그대로 사용할 수 있나? 그렇다.

• 코틀린의 클래스나 메서드를 일반적인 자바 클래스나 메서드와 똑같이 사용할 수 있다.
  • 기존 자바 프로젝트에 코틀린을 도입할 경우 자바를 코틀린으로 변환하는 도구를 코드 베이스 안에 있는 자바 클래스에 대해 실행해서 그 클래스를 코틀린 클래스로 변환할 수 있다.
  • 코틀린이 집중하는 상호운용성 방향은 기존 자바 라이브러리를 가능하면 최대한 사용하는 방향이다.
  • 코틀린이 제공하는 풍부한 API는 실행 시점에 아무런 부가 비용을 야기하지 않는다.
• 코틀린이 제공하는 도구도 다중 언어 프로젝트를 완전히 지원한다.
  • 자바와 코틀린 소스 파일을 자유롭게 내비게이션 할 수 있다.
  • 여러 언어로 이뤄진 프로젝트를 디버깅하고 서로 다른 언어로 작성된 코드를 언어와 관계 없이 한 단계씩 실행할 수 있다.
  • 자바 메서드를 리팩토링해도 그 메서드와 관련 있는 코틀린 코드까지 제대로 변경된다.(반대도 성립)