[레벨 0] 2주차 학습 기록 및 회고

2주차 학습을 마무리 하면서

평일에 생각보다 진도를 나가지 못해서 주말동안 복습보다는 새로운 학습에 초점을 두었습니다. 갑작스러운 일정과 환경 변화로 인해 충분히 집중하지 못한 점은 아쉬움으로 남습니다. 하지만 바쁜 와중에도 학습의 끈을 놓지 않고 이어갔다는 점에 의의를 두고 싶습니다. 가장 인상 깊었던 내용은 확장 함수였습니다. 확장 함수를 통해서 사용 시점에 따라서 객체가 가지는 행위를 유연하게 추가할 수 있다는 것이 클래스를 가볍고 이해하기 쉽게 만든다는 것을 알았습니다. 앞으로 최대한 확장함수로 먼저 구현 후 중복이 발생하면 멤버 메서드로 바꾸는 연습을 해야겠습니다. 다음 주 역시 많은 시간 확보는 어렵겠지만 학습과 휴식의 경계를 명확히 구분하여 짧은 시간이라도 밀도 있게 집중하고자 합니다.

---

화요일(02.03)

Fact(배운 것)

• 코틀린 인 액션 2장 나머지

Finding(알게된 것)

1. 클래스와 접근자 메서드에 자동으로 붙는 final

코틀린에서는 기본적으로 클래스와 접근자 메서드(getter, setter)에 final이 붙는다는 것을 알 수 있었습니다. 또한 기본 가시성은 public이라는 것도 확인할 수 있었습니다.

 

2. 왜 자바는 public 클래스명과 파일명이 같아야할까?

자바가 이러한 규칙을 만든 이유는 개발자에게 더 많은 선택권을 쥐여줄수록 개발 경험을 악화시킬 수 있기에 사용성과 유지보수성을 높이고자 이런 규칙을 강제했다는 것을 알 수 있었습니다.

• Why are filenames in Java the same as the public class name?

 

3. 빌더 패턴과 코틀린의 디폴트 파라미터, 이름 붙인 인자

Why are filenames in Java the same as the public class name? 글을 읽으면서 빌더 패턴이 나오길래 찾아보았는데 코틀린의 디폴트 파라미터와 이름 붙인 인자를 사용하면 빌더 패턴이 가지는 모든 장점을 가져가면서도 불필요한 코드가 없어지는 것 같습니다.

 

자바는 디폴트 파라미터와 이름 붙인 인자의 개념이 없어서 빌더가 필요했던 것 같습니다.

• 빌더 패턴(Builder Pattern)을 사용해야 하는 이유 
• 빌더 패턴과 디폴트 파라미터

Feeling(느낌)

단순해 보이는 기능 하나 하나가 중요한 역할을 할 수 있다는 것을 깨달았습니다.

---

수요일(02.04)

Fact(배운 것)

• 코틀린 인 액션 3장 일부

Finding(알게된 것)

1. 컴파일러가 생성하는 클래스 이름이 중복된다면?

최상위 함수를 JVM에서 실행하기 위해 컴파일러가 자동으로 생성해주는 클래스([파일명]Kt)와 동일한 이름의 클래스를 직접 선언하면 어떻게 될지 궁금했습니다. 확인해 본 결과 컴파일 에러가 발생함을 확인할 수 있었습니다.

 

2. 자바에서 코틀린 확장함수 사용해보기

첫 번째 인자가 수신 객체인 정적 메서드 호출에 대한 문법적 편의로 사용되는 확장 함수를 자바에서 사용해봤습니다.

• 수신 객체의 컴파일 시점 타입에 의해 결정되는 것으로 런타임의 실제 저장된 값은 중요하지 않습니다.

Feeling(느낌)

이제 3장을 읽고있는데 다음주까지 8장을 더 읽을 수 있을 지 걱정이 됩니다..

 

---

금요일(02.06)

Fact(배운 것)

• 코틀린 인 액션 3장 마무리
• 자바 String / StringBuffer / StringBuilder 차이점 & 성능 비교

Finding(알게된 것)

1. vararg는 내부적으로 배열 형태로 들어간다!

바이트코트를 보면 탑레벨 함수 sum의 인자로 String의 레퍼런스 배열을 의미하는 [Ljava/lang/String이 들어감을 볼 수 있습니다. 따라서 vararg는 내부적으로 배열로 변환된다고 추측해볼 수 있었습니다.

• How does JVM implement the varargs?

2. 코틀린에서 원시 타입의 배열을 만드는 방법?

Array는 레퍼런스 배열을 만드는 반면 IntArray 등을 사용하면 원시 배열을 만들 수 있다는 것을 알았습니다. 그런데 Int타입을 원시타입으로 쓸 수 있는 지 궁금해졌고 시험해본 결과 코틀린이 알아서 원시 타입 혹은 객체(ex. int vs Integer)를 생성함을 알 수 있었습니다.

• Array에 저장될때는 코틀린이 자동적으로 Integer를 만듭니다.
• 기본적인 덧셈을 할 때는 int 원시 타입으로 처리됩니다.

Integer 객체를 생성해 레퍼런스 배열에 저장하는 모습

간단한 덧셈의 경우 Integer 객체를 생성하지 않는 모습

 

이건 안됩니다..

 

참고한 글

• Does Kotlin have primitive types?
• Kotlin Documentation: Primitive-type arrays

아래 글을 통해서 invokestatic의 결과(Integer 객체)가 오퍼랜드 스택에 존재하고 aastore 명령의 형식에 맞음을 확인할 수 있었습니다.

• JVM 2.6.2. Operand Stacks: Other Java Virtual Machine instructions take operands from the operand stack, operate on them, and push the result back onto the operand stack.

3. 구조 분해 문법의 동작

구조 분해 문법은 내부적으로 Pair의 메서드인 component1 등을 사용하는 것을 알 수 있었습니다. 바이트코드를 보면서 궁금했던 점은 왜 Int 타입이 아닌 Number 타입으로 처리하는 걸까하는 의문이 들었습니다.

Feeling(느낌)

• 이동하는 시간이 많아서 그런 지 정신이 하나도 없는 느낌입니다..
• 확장함수를 적극적으로 활용해봐야겠다는 생각이 들었습니다.

---

토요일~일요일(02.07~02.08)

Feedback(피드백)

• 취약한 기반 클래스와 리스코프 치환 원칙(LSP) 학습
  • 다음과 같은 이유 때문에 취약한 기반 클래스(상속)이 문제가 된다고 생각합니다.
    1. 요구사항이 변함에 따라 리스코프 치환 원칙을 만족하던 올바른 is-a 관계가 깨질 수 있다는 점
    2. 상속은 대부분의 언어에서 하나만 가능하기에 부모가 커지기 쉬우며 의존하는 객체가 많아질수록 수정에 대한 파급력이 커지고 리스코프 치환 원칙을 어길 확률이 높아진다는 점
• 평일동안 학습 내용이 적어서 4장을 추가 학습

Future(계획)

계속 인텔리제이 IDE를 사용하지 않고 공부를 해왔는데 더 많은 시간이 필요했고 불편함에 실습해보는 것에 소극적이게 된다는 느낌을 받았습니다. 다음 주차는 시간이 부족한만큼 인텔리제이로 실습을 진행하면서 디컴파일러를 활용해 살펴보고자 합니다.