2022.05.05 기록장

ToDo

• 코틀린 공부 9장
• 리액트 튜토리얼
• 기획 확인

Done

• 코틀린 공부 9장

 

Weekly goal

• 코틀린 공부
• 리액트 공부
• 피드백 정리

 

let함수 변경

- 값이 nullable일 때 ?. 하지 않으면 에러 발생
- let 함수의 목적에 맞게 null이 불가능한 함수에 nullable 객체를 넘길 수 있다

타입 파라미터에 제네릭 제약 가하기

- 2개 이상의 제약을 가할 수 있다

제네릭은 타입이 실행 시점에 지워짐

- 지워지기에 무슨 List인지 검사는 불가능하다
- 지워짐으로서의 이점은 저장해야하는 타입 정보의 크기가 줄기에 전반적인 메모리 사용량이 줄어든다

- 리스트는 리스트인줄 알 수 있지만 map은 리스트인지 검사하려면 스타 프로젝션(*)을 사용해야한다

as를 통한 캐스팅시 컴파일 경고

- set등이 들어오면 casting exception이 발생한다
- 근데 List<String>이 들어오면 리스트 내부는 검사할 수 없으므로 통과된다
- 후에 sum 실행시 오류가 발생

filterIsInstance 사용기

- 이는 line를 사용한 함수이다. 내부를 보면 제네릭을 사용하고 실체화를 이용하여 타입을 런타임 시점에 알아낸다
- 인라인은 항상 쓰지말고 함수의 파라미터 중에 함수 타입인 파라미터가 있고 해당 파라미터와 함께 인라이닝함으로써 얻는 이익이 더 큰 경우에만 함수를 인라인 함수로 만들어야한다
- 이경우는 런타임시점에 알기를 원했기에 사용하는 것이다

서비스로더를 런타임 시점에 사용해 보기

- 해당하는 타입을 런타임 시점에 파악하여 인스턴스를 구할 수 있다

변경 가능 제네릭 리스트를 파라미터로 넘기는 것은 컴파일 에러

- 변경가능한 리스트는 값을 사용할 때 에러가 발생할 수 있으므로 컴파일러가 애초에 막는다
- 단 읽기 전용은 읽기만 하면 상관 없으므로 에러가 발생하지 않는다

공변

- mutable<Any>는 muatable<String>의 상위 타입이 아니다
- 이유는 앞에 설명한 것 처럼 에러가 발생할 수 있기 때문이다. 상위 타입을 하위타입으로 바꿀 때 문제가 없어야지만 상위 타입과 하위 타입 관계라 말할 수 있다
- list<Any>는 list<String>의 상위 타입이다

- mutable은 타입 a와 b가 다르기만 하면 하위 타입이 아니기에 무공변이라고 한다
- list는 a와 b가 다르지만 하위 타입이면 공변적이라고 한다

- 공변적으로 나탈낼때는 out을 붙인다

out 키워드

- 클래스의 타입을 공변적으로 만들면 함수 정의에 사용한 타입과 인자의 타입이 정확히 일치하지 않더라도 그 클래스이 인스턴슬르 함수 인자나 반환값으로 사용할 수 있다
- cat은 animal의 하위 클래스이긴 하지만 변성을 선언해주지 않았기에 하위 클래스가 아니다
- 타입 캐스팅을 하면 풀 수 있지만 번거롭고 올바른 방법이 아니다

out 키워드 해결

- out을 사용하면 공변적인 클래스로 만들면 된다
- 하위 클래스도 공변적으로 바꿀 수 있다
- 하위 클래스도 공변을 선언해야지만 사용가능하다

- 타입 파라미터를 공변적으로 만들면 항상 out 위치에 존재해야한다
- 생산하는 위치(반환)에 있어야 한다. in(파라미터)의 위치에는 있을 수 없다

out 키워드의 위치

- mutable은 out이 붙어있지 않다
- 이들은 파라미터에 타입 파라미터가 사용되어야 하기 때문이다
- out에서 in자리에 타입 파라미터가 없는 것은 하위 타입의 안전서을 지키기 위해서이다
- 단 생성자 파라미터는 아웃,인 어디도 아니다
- 근데 var로 생성자에서 선언하면 변경 가능이므로 set을 선언한 것과 같다. 그래서 in의 위치가 된다
- 변성은 위험할 수 있는 코드 호출을 막을 수 있다

in 키워드

- comparator는 타입 파라미터를 소비하기만 하므로 in을 붙여야한다
- in도 메소드 호출을 막기위해서 사용됨
- out T는  <? extends T>와 같고 in T는 <? super T>와 같다고 생각하라

* 사용기

- 스타 프로젝션은 any?와 는 다르다 들어올 타입을 모르지만 하나만 들어올 수 있다는 것이다
- 오류는 타입 캐스팅시 생기지 않고 사용시 발생한다

* 사용기 리팩토링

- 타입 캐스팅은 이제 프로그래머의 책임이다. 이는 실수를 유발할 수 있다
- 객체로 감싸서 사용할 수 있게 되었다

object는

- 싱글톤 객체를 만들때 사용
- 동반 객체를 만들 때 사용 -> static 메소드,필드를 만들 때
- 무명 내부 클래스 대신 사용

 

GitHub - ChoiGiSung/KotlinInAction