[내 맘대로 정리한 안드로이드] Java와 Kotlin에서의 접근 제한자

 

 

접근 제한자

Java와 Kotlin은 지극히도 객체 지향적인 언어다.

모든 기능들이 Class, 객체의 형태로 연결되어 작동한다.

 

이런 객체지향적인 구조에서는 Class간에 어떤 정보를 공개할 것이고 또 어떤 정보를 숨길 것인지가 중요하다.

어떤 경우에는 클래스의 외부 사용자가 직접 건드려서 사용해야 하는 함수나 변수 등등이 있을 수 있고,

또 반대의 경우에는 외부에서 직접 건드려서는 안 되는 내용이 클래스 내에 포함될 수도 있다.

각 요소마다 이에 대한 설정을 관리해주는 것이 '접근 제한자'이다.

 

Java에서의 접근 제한자 (Access Modifiers)

Java에서 사용되는 접근 지정자에는 4가지 종류가 있다.

아래는 다른 블로그 (이를테면 https://luyin.tistory.com/232) 에도 많이 소개되어 있는, 각각에 대한 표이다.

 

	public	protected	package-private	private
모든 경우	o	x	x	x
하위 클래스	o	o	x	x
같은 패키지	o	o	o	x
같은 파일	o	o	o	o

 

public > protected > package-private > private 순서로 접근이 개방되어 있다고 볼 수 있다.

 

따로 변수나 함수 앞에 public 등의 접근제한자를 달지 않는다면, 

기본으로 설정되는 접근제한자는 package-private이다.

 

Kotlin에서의 접근 제한자 (Visibility Modifiers)

Kotlin에도 마찬가지로 접근 제한자(Visibility Modifiers)가 있다.

Java와 거의 동일하나, 두 가지 차이점이 있다.

 

1. package-private가 아닌 internal이 사용된다.

즉, public, protected, internal, private이다.

internal은 package-private와 비슷하면서도 다르다.

 

package-private가 '같은 패키지 내'에서 접근이 가능하다면,

internal은 '같은 모듈 내'에서 접근이 가능하다.

이때 '모듈'이란 코틀린 공식 문서에 따르면 아래 4가지를 포함한다.

 

- an IntelliJ IDEA module;

- a Maven project;

- a Gradle source set (with the exception that the test source set can access the internal declarations of main);

- a set of files compiled with one invocation of the <kotlinc> Ant task.

 

일반적으로 우리가 제작하는 애플리케이션 프로젝트 내에서라면,
기본적으로는 제일 메인인 app 모듈을 예로 들 수 있겠다.
따라서 단일 app으로만 되어 있는 간단한 프로젝트의 경우에는 프로젝트의 어디서든 internal 요소에 접근 가능하다.

반면 여러 라이브러리 모듈을 합쳐 사용하는 경우에는, 하나의 라이브러리를 그 단위라고 볼 수 있을 것 같다.

즉, 같은 라이브러리 내에서라면 어디서든 접근할 수 있다는 의미가 될 듯.

 

2. 기본 접근 제한자가 public이다.

java에서는 package-private가 기본적인 접근제한자이지만,

kotlin에서는 따로 접근 제한자를 설정해주지 않으면 public으로 설정이 된다는 차이점이 있다.

 

Q. 왜 두 언어에서의 영문 표기가 다를까?

문득 궁금해졌다.

왜 Java에서는 Access Modifier, Kotlin에서는 Visibility Modifier일까?

Kotlin의 공식 문서에서 Visibility라는 단어를 차용한 이유에 대해서는 나와 있지 않았다.

 

두 언어에서의 접근제한자가 package-private, internal에서 차이가 두드러진다는 면에서 한 번 생각해 보았다.

package-private는 한 프로젝트 내에서도 같은 '패키지'여야만 접근할 수 있다.

반면 internal은? 같은 모듈 내 어디에서든 접근이 가능하다. 

그렇다면 주로 단일 app 모듈 내에서 작업하는 개발자 입장에서는 accessibility 면에서 public과 internal의 차이가 와닿지 않을지도 모른다.

Visibility라는 단어를 활용하면 '이 프로젝트 외부에게서 이 요소를 숨긴다'라는 의미를 담을 수 있지 않을까?

 

곰곰히 생각해 보니 package-private와 internal만의 문제가 아니라,

애초에 Visibility라는 단어가 접근제한자의 목적성에 더 알맞다는 느낌이 들었다.

처음부터 접근제한자의 목적은 객체지향의 요소 중 하나인 Encapsulation이다.

어디까지를 '보여주고' 어디서부터 '숨길' 것인가?'

나 역시도 이 글의 초장부터 무의식적으로 '공개'라는 단어를 쓰기도 했다.

그렇다면 처음부터 Visibility가 먼저이고 그 다음이 Access라고 봐야 하는 게 맞지 않을까?

 

답은 알 수 없지만...... 이런 저런 생각을 해 보았다.