1️⃣ 오늘의 Keyword
- nullable, non-null
- 엘비스 연산자
- throws
- checked exception
- constructor
- 주 생성자
- 보조 생성
- init
2️⃣ 학습 내용 및 예시
- Null Safety
- nullable type : ? 기호를 이용해 null이 될 수 있는 변수로 선언 (Int?, String?)
- 타입 캐스팅적인 면에서보면 nullable 타입니다 non-null 타입보다 상위로 취급
- Any? ← Any 묵시적 변환
- Any ← Any? : as로 명시적 변환
- operator
- ?
- ?:
- 엘비스 연산자
- null 이면 실행할 기본값 설정
- ?. (A?.length)
- 멤버접근 연산자
- A가 null이면 결과값이 null, 아니면 length
- A?.let { }
⇒ null이 아닌 경우 { } 구문 실행 - !! (A !! B)
- A가 null 이 아닌경우만 B실행, null이면 Exception 발생
- 예외처리 순서
- 정상처리 - App 내에서 있을 수 있는 에러를 정상 상황으로 처리
- 예외전파 - throw
- try - catch - finally
- 예외 상하위 관계가 있는 경우, 하위 예외부터 처리해야함.
- Java: Checked Exception이 있어서 예외를 반드시 try–catch로 처리하거나 throws로 선언해야 한다.
- throws: 이 메서드는 특정 예외가 발생할 수 있으니 호출자가 처리하라고 선언하는 것.
- checked exception: 컴파일 시점에 반드시 처리(try–catch)하거나 throws로 넘겨야 하는 예외.
- Kotlin: Checked Exception이 없어서 throws 강제가 없고, 모든 예외는 unchecked다.
- 예외 발생시키기
- 아마도 예외를 error가 아니라 컨트롤 할 수 있는 대상으로 인식하는 방향성(?)
- Exception 클래스
- 프로그램적으로 예외상황 자체를 객체로 만든 것.
- 사용자 예외 클래스를 생성해서 사용가능.
- 예외 상황을 타입별로 분류해서 다룰 수 있게 함. (자의석 해석)
- Java Class
- jvm 언어에서 메모리를 할당하고, 주소를 무조건 return 함
⇒ return 과 관련된 어떤 예약어도 붙일 수 없음 - Java에서 클래스의 로직과 메모리 할당 순서
- 클래스가 선언(인식)되는 순간 static 멤버 메모리 할당 (한번만)
- 다른 생성자 호출 (this, super)
- 메모리 할당
- 로직 실행
- Kotlin Class
- 클래스 body 가 없다면 { } 생략 가능
- 코틀린 파일에 파일명과 같은 클래스가 없어도 된다 (권장하지않음)
- constructor : 생성자 예약어
- 주 생성자 (Primary Constructor)
- 하나의 클래스에 하나의 주 생성자만 정의 가능.
- 컴파일러가 자동으로 생성해주는 Default 생성자도 주 생성자이다.
- 주 생성자는 실행문 { } 을 가질 수 없다
- 필요시 inti 예약어로 따로 명시하는 기법 사용
- 생성자 매개변수 ⇒ class의 멤버를 초기화하는데 사용됨
- 주 생성자의 매개변수에 한해서 var val을 붙여 class의 멤버변수로 적용 가능
- 보조 생성자
- 클래스 바디 영역에 constructor 예약어로 선언
- 보조 생성자를 선언했으면 주 생성자는 선언하지 않아도 됨
- 주, 보조 생성자를 개발자가 추가하면 컴파일러는 주 생성자 자동생성x
- 생성자는 클래스 선언시 최소 하나 이상 정의되어 있어야 한다
- init로 정의한 초기화 블록은 주 생성자든 보조 생성자든 객체 생성 때 가장 먼저 실행된다. (단 보조생성자 위주로 개발할 때, init을 거의 사용하지 않음)
- 보조 생성자의 매개변수를 선언할 때 주 생성자처럼 var, val를 추가해서 선언 불가.
❓ 이해 안 된 부분 / 도움 요청
- java에서 자주 클래스의 멤버변수에 직접적인 접근을 막기 위해 private을 붙이고 getter와 setter를 만들어 클래스 밖에서 값에 접근하는걸로 배웠습니다
그런데 코틀린에서 주 생성자의 매개변수에 val나 var을 붙여 클래스의 멤버변수로 적용해 사용할 때에는, 자바에서처럼 클래스 외부에서 변수에 접근을 제어하기 어려운거아닌가? 라는 의문이 생기면서
=> 아 나중에 접근제어자에 대한 이야기가 나올 때 또 추가설명 개념 설명이 나오겠구나
이렇게 생각이 흘렀고,그러면서 좀 현재는 필요하지 않은 질문을 했던 것 같습니다.자바이든 코틀린이든 private으로 멤버변수가 캡슐화, 되어 있지 않은 상황에서는 어짜피 getter 와 setter가 똑같이 필요하지 않으니까요.이런 생각의 흐름이 맞나요??
Made with Bullet