11장. 속성 메서드
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
Java는 프로퍼티 액세스 메서드와 다른 유형을 구분하지 않습니다. 반면에 Kotlin은 프로퍼티를 멤버 함수와 다르게 취급합니다. 결과를 반환하는 함수보다 계산된 프로퍼티를 선호해야 하는 경우는 언제일까요?
필드, 접근자 및 속성
대부분의 프로그래밍 언어( )에서는 어떤 방식으로든 데이터를 그룹화하여 복합 속성에 이름(및 종종 유형)을 지정할 수 있습니다.
예를 들어 은 3개의 필드로 구성된 레코드로, 레코드 타입을 지원하는 최초의 범용 언어 중 하나인 ALGOL W로 작성되었습니다. (ALGOL W는 Tony Hoare가 널 참조를 도입한 언어이기도 합니다.)
RECORD PERSON (
STRING(20) NAME;
INTEGER AGE;
LOGICAL MALE;
);
당시에는 실제 프로그래머는 대문자만 사용했고 성별은 부울(Boolean)이었습니다.
ALGOL W에서는 PERSON 레코드에 보관된 나이를 업데이트할 수 있습니다(물론, 할 수 있습니다):
AGE(WILMA) := AGE(WILMA) + 1;
이 경우 컴파일러는 레코드의 메모리에 접근하여 윌마의 나이를 나타내는 바이트를 찾아서 증가시키라는 명령을 내립니다. 다른 언어에서는 구조체라고도 하는 레코드는 관련 데이터를 그룹화하는 데 편리합니다. 여기에는 정보가 숨겨져 있지 않고 구성만 있을 뿐입니다.
대부분의 초기 객체 지향 시스템(특히 C++)은 이 레코드 메커니즘을 기반으로 했습니다. 인스턴스 변수는 단순히 레코드 필드이고 메서드(일명 멤버 함수)는 함수에 대한 포인터를 포함하는 필드였습니다. Smalltalk는 달랐습니다. Smalltalk 객체는 인스턴스 변수를 가질 수 있지만 이 상태에 액세스하려면 값을 요구하는 메시지를 객체에 전송해야 합니다. 필드가 아닌 메시지를 근본적으로 추상화하는 것이죠.
Java 구현자는 각 접근 방식을 조금씩 취했습니다. 객체는 공용 필드를 가질 수 있지만 클라이언트는 이를 검색하기 위해 메모리에 접근할 수 없으며, 바이트코드 명령을 호출하여 값에 액세스해야 합니다. 이렇게 하면 런타임에서 비공개 필드에 대한 액세스를 강제하면서 클래스를 레코드로 처리할 수 있습니다.
필드에 대한 직접 액세스는 허용되었지만 처음부터 권장되지 않았습니다. 클라이언트가 필드에 직접 액세스하면 적어도 해당 클라이언트도 변경하지 않고는 데이터의 내부 표현을 변경할 수 없습니다. 또한 클라이언트가 필드를 직접 변경할 수 있으면 필드 간의 불변 관계를 유지할 수 없으며, 5장에서 살펴본 것처럼 당시에는 객체가 변이에 관한 모든 것이었습니다. 필드 액세스도 다형성이 아니므로 서브클래스가 구현을 변경할 수 없습니다. 당시에는 서브클래싱도 객체에 관한 모든 것이 었습니다.
따라서 Java에서는 필드에 직접 액세스하는 대신 일반적으로 접근자 메서드인 getter와 (필요한 경우) setter를 작성합니다. Getter는 ...