분류 전체보기

    Kotlin Class Member 가시성 변경자 : public, internal, protected, private 의 차이

    목표 클래스 멤버의 가시성 변경자에 대해 이해한다. 클래스 멤버의 가시성 변경자 Kotlin은 클래스 내부에 클래스 멤버(class, fun, val, var)를 선언하고 외부에 변수를 참조하게 만들 수 있다. 하지만, 모든 클래스 멤버들이 외부에서 가시적이라면 클래스에 대한 무분별한 참조가 일어나 캡슐화가 깨질 수 있다. 이러한 상황을 방지하기 위해 클래스 멤버들에는 가시성 변경자를 설정할 수 있도록 한다. 클래스 멤버에 설정 가능한 가시성 변경자는 4가지이다. public : 모든 곳에서 접근 가능 internal : 모듈 내부에서만 접근 가능 protected : 해당 클래스 멤버가 포함된 클래스를 상속받는 클래스에서 접근 가능 private : 같은 클래스 내부에서만 접근 가능 Internal :..

    Kotlin 최상위 선언에서 가시성 변경자 : public, internal, private

    목적 최상위 선언의 가시성 변경자에 대해 이해한다. internal 가시성 변경자에 대해 이해한다. 최상위 선언에서의 가시성 변경자 최상위 선언에서는 3가지의 가시성 변경자를 쓸 수 있다. public : 기본 가시성 변경자이다. 모든 곳에서 접근 가능하다. internal : 같은 모듈 안에서만 접근 가능하다. Kotlin의 특별한 접근자로, 이 접근자를 통해 모듈화가 수월해진다. private : 같은 파일(.kt)안에서만 접근 가능하다. 최상위 선언에는 여러 class와 메서드(fun), 변수(val, var)이 들어갈 수 있는데, private으로 선언되었다면 같은 파일 안에서는 언제나 접근 가능하다. 아래에서 internal과 private 접근 제한자에 대해 살펴보자 Internal 접근 제한..

    Kotlin의 가시성 변경자(접근 제한자) : public, internal, protected, private

    목적 최상위 선언의 가시성 변경자에 대해 이해한다. 클래스 멤버의 가시성 변경자에 대해 이해한다. 가시성 변경자 가시성 변경자는 클래스에 대한 외부 접근 권한을 제어한다. Kotlin에서는 4가지 가시성 변경자를 제공한다. public internal protected private Kotlin에서는 최상위 선언에서의 가시성 변경자와 클래스 멤버 선언에서의 가시성 변경자의 접근성이 달라진다. 먼저 공통적으로 적용되는 가시성 변경자인 public에 대해 알아보자. public public은 기본 가시성 변경자로, 어디에서나 접근 가능한 가시성 변경자이다. Kotlin에서는 아무것도 쓰지 않을 때 public이 기본 가시성 변경자로 설정된다. 이는 가시성 변경자를 쓰지 않을 때 default라는 별도의 가시..

    Kotlin, Java의 최상위 선언 차이점

    목표 Java와 Kotlin의 최상위 선언의 차이에 대해 이해한다. 최상위 선언 최상위 선언이란 파일 최상위에 선언되는 클래스, 메서드, 변수를 뜻한다. Java의 최상위 선언 Java에서는 모든 코드가 클래스 기반으로 작성된다. 이 때문에 자바의 모든 파일은 클래스에 연결되어 있는데, 이로 인해 아래와 같이 최상위 선언에는 클래스만이 들어올 수 있는 구조가 만들어진다. package apackage; public class GalaxyTab { .. } 따라서 자바에서의 최상위 선언에는 class만이 들어갈 수 있으며, 파일명과 같은 클래스만이 정의가 가능하다. 메서드를 정의하기 위해서는 class 내부에 정의를 해야 한다. 이러한 구조에서는 메서드를 정의하기 위해 클래스를 만들고 내부에 메서드를 만들..

    Kotlin의 상속 변경자 : final, abstract, open

    목적 Kotlin의 상속 변경자가 어떻게 설계되었는지 이유와 의미를 이해한다. 개요 Java에서는 class는 기본적으로 상속이 가능했다. 상속을 불가능하게 만들기 위해서는 final 변경자를 붙여야 했다. 객체 지향적인 관점에서는 객체가 있고 해당 객체에 대한 코드를 줄이기 위해 재사용 가능하다면 재사용 하는 것이 좋지만, 이러한 사용 방식은 상속하는 기반 클래스가 변경이 없는 경우에만 유효하다. 기반 클래스가 변경이 잦은데 무분별하게 클래스를 상속하게 된다면, 취약한 기반 클래스(fragile base class) 문제에 직면하게 된다. 기반 클래스가 변경될 때마다 기반 클래스를 상속하는 모든 자식 클래스들은 변경되어야 하며, 어느 부분에 문제가 생길지 모른다. 이러한 문제를 해결하기 위해 코틀린에서..