55,000원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)
stop, down to 함수질문
stop, down to 가 함수라고 설명해주셨는데, 큰 범위의 수를 도는 반복문에 stop, down to 가 호출되면 스택오브플로우와같은 에러가 발생하지 않는 이유는 무엇인가요..?
- 미해결자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)
질문 드립니다.
변수에 숫자값을 대입하실때 아래와같이 선언하시는데 _ 가 의미하는것이 무엇인가요? var money 1 = 1_000L 1_000 에서의 _ 를 여쭤본것입니다!
- 미해결자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)
질문 있습니다.
코틀린에서는 null 사용을 안전하게 하기 위해서 null 이 들어갈 수 있는 변수를 완전히 다른 타입으로 간주하고 아래와 같이 효과적으로 관리할 수 있다. 라고 말씀해주셨는데요 그렇다면 String과 String? 타입은 엄연히 다른 타입 인것이고 String? 이 자체를 하나의 타입으로 간주해야하는건가요? String? 이렇게 생긴 타입은 코틀린에서는 클래스로 정의 되어 있지 않아서요..!
- 해결됨자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)
abstract class와 sealed class는 어느경우에 나눠 사용하나요?
좋은 강의 감사드립니다. 🙇♂️ 한 가지 의문이 있습니다. sealed class를 사용하는 목적이 계층 구조를 안전하게 만들고 싶다로 이해됩니다. 또한, 문서를 보아하니 sealed class자체가 abstract class인것 같은데, 기존의 abstract class를 사용하는 경우도 대부분 주로 계층화에 많이 사용되지 않았습니까? 예를 들자면 interface -> abstract class -> class 순으로 점차 구체화 해나가는 식으로요. 그럼 그냥 abstract class를 사용해야 할 필요를 느낄 경우에 항상 sealed class를 사용해버리면 when을 쓸 때 안정성만 더 증가하는 것 같은데, 코틀린에서 abstract class는 언제 사용하나요? 정리하자면, abstract class를 사용하면 아무나 이를 서브클래싱 하여 확장할 수 있으나, 실제 자바의 코드들은 이러한 용도로 사용되고있진 않습니다. (이러한 상황 자체가 sealed class의 탄생 배경으로 이해 됩니다). 따라서 sealed class자체가 abstract class의 super set인 것 같은데, 이렇게 되면 abstract class를 사용했을 때의 베네핏이 있나요? 실제 코틀린으로 업무를 보시면서 abstract class를 사용하시는 경우가 있는지 궁금합니다. 당장 드는 생각은 대부분의 경우를 abstract class가 아닌 sealed class로 퉁쳐도 될 것 같다고 생각되어서요.... 🤔
- 미해결자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)
3. 클래스를 상속받을 때 주의할점 질문
그 Base 와 Derived를 설명 해 주실 때 1. 상위 클래스 생성자가 실행되는 동안 하위 클래스의 프로퍼티 즉 Derived를 인스턴스화 한다는 말은 2. Derived에 있는 number에 값을 집어 넣어준다는 건데 3. 이때 상위 클래스에서 넘버를 호출하게 되면 하위 클래스에 있는 넘버를 가져오잖아요 4. 근데 아직 상위 클래스의 constructor가 먼저 실행된 단계라서 하위 클래스에 number 라는 값에 초기화가 이루어지지 않아서 0 이 나오는 거에요. (3.)을 삽질을 조금 해가며 찾아봤었는데, 제가 이해했는게 맞는지 질문드립니다. "open 된 부모 클래스의 필드는 사용자가 지정한 값을 무시하고, 기본 값을 할당한다. 이후 자식 클래스에서 같은 이름의 필드를 만들어 사용한다. (쉐도잉)" 그래서 부모 클래스 Base init {..} 안에 open 필드를 사용하면 기본값이 나온다고 이해 했습니다. 제가 이해한 내용이 맞을까요? - - <장문 주의> - - 이런 결론을 내게된 과정은 아래와 같습니다. 자바로 디컴파일을 해보니, 코틀린은 생성자를 여러 개를 역할 나눠 순서대로 사용하더라구요. 1, (기본 값) (사용여부를 나타내는 이진수) (기본생성자 마커)각 매개변수에 넣을 기본 값을 지정. var 로 선언하더라도 동일 public Base() { this(0, 0, 0, 0, 0, 31, (DefaultConstructorMarker)null);} 2. (사용여부를 나타내는 이진수)를 바탕으로 초기화를 하는 생성자 예) 총 5개중에 첫번째, 세번째 변수 사용 => 10100 public Base(int var1, int var2, int var3, int var4, int var5, int var6, DefaultConstructorMarker var7) { // 매개 변수를 5개를 사용해서, 6번째에 사용여부 이진수를 넣음 if ((var6 & 1) != 0) { var1 = 100; } if ((var6 & 2) != 0) { var2 = -1; } if ((var6 & 4) != 0) { var3 = -11; } if ((var6 & 8) != 0) { var4 = -22; } if ((var6 & 16) != 0) { var5 = -33; } this(var1, var2, var3, var4, var5) 3. 일반적인 생성자 코드와 init {...} 안의 내용 public Base(int number, int base, int hoho, int hihi, int hehe) { this.number = number; this.base = base; this.hoho = hoho; this.hihi = hihi; this.hehe = hehe; String var6 = "Base Class " + this.base; System.out.println(var6); var6 = "B " + this.getNumber(); System.out.println(var6);} 즉 Base 부모 클래스에는 open 한 변수들은 바로 위에 적힌 (3. 생성자)를 통해 기본값이 할당된 상태로 그냥 존재하더라구요. public class Base { private final int number; // open 한 매개변수 private final int base; // open 한 매개변수 private final int hoho; private final int hihi; private final int hehe; 이후 Derived 자식 클래스에 의해 부모 클래스의 매개변수들이 가려졌었습니다. public final class Derived extends Base { private final int number; private final int derived; 자식 클래스의 초기화 여부와 상관없이 부모클래스 안에서, 부모 필드를 호출했으니 0이 나오게 되는 거더라구요. 이후 자식 객체에서 같은 이름으로 쉐도잉 되는데, 가려졌을 뿐 힙 메모리 상에는 부모클래스의 필드는 그대로 0 이구요. 제가 이해한 내용이 맞을까요? ---------------- 혹시 getter 로 접근하는 것과 필드에 직접 접근하는 거에 차이가 있는건가 싶어서, 그것도 확인해보았는데 - 내부에서만 사용하는 경우 getter로 접근하지 않고 직접 필드 접근으로 최적화 되었습니다. String var3 = "Derived Class " + this.derived;System.out.println(var3); - open 을 사용하거나 override된 필드는 getter로 접근하더라구요. var3 = "D " + this.getNumber();System.out.println(var3); 근데 최적화의 차이만 있을 뿐, this.number 로 변경되더라도 결과는 다르지 않을 듯 합니다. Base init{..} 은 어차피 부모 필드를 호출하게 되니까요.