10-1.캡슐화

10-1-1.액세스 지정자

클래스에 소속된 필드는 칭할 때 소속 객체를 밝힌다는 차이만 있을 뿐 값을 저장하는 기능은 일반 변수와 같다. 외부에서 자유롭게 읽고 쓸 수 있다 보니 다음과 같은 엉뚱한 코드를 작성할 가능성이 있다.

Time now = new Time();

now.hour = 34;

now.minute = 80;

now.second = 99;

시, 분, 초의 범위를 벗어난 값을 대입했다. 분은 0 ~ 59까지만 가능한데 80을 대입해도 아무 이상 없다. 컴파일러는 minute 필드가 정수형이라는 것만 알 뿐 논리적인 의미는 모르니 정수 범위의 값을 순순히 대입할 수밖에 없다. 34시 80분 99초는 상식적으로 말이 안되며 now 객체는 시간값으로 부적합한 쓰레기이다.

무효한 객체를 고의로 만들지는 않겠지만 초보 개발자의 황당한 실수나 버그로 인해 엉뚱한 값이 대입될 가능성은 있다. 무효한 객체는 이후 어떤 문제를 일으킬지 알 수 없는 시한폭탄이 되어 안정성을 위협한다. 더 심각한 것은 문제를 일으킨 곳과 말썽이 생기는 곳이 달라 잘못을 즉시 알 수 없다는 점이다. 거대한 기계도 사소한 부품 하나가 잘못되면 제 역할을 할 수 없다.

이런 문제가 발생하는 원인은 멤버가 외부로 공개되어 있어 누구나 찝쩍댈 수 있기 때문이다. 안전성 확보를 위해 중요한 멤버를 아무나 건드리지 못하도록 숨길 필요가 있다. 고의든 실수든 잘못된 방법으로 객체를 조작하더라도 이를 거부하고 무결성을 지키도록 방어해야 한다.

객체가 부주의한 사용으로부터 오동작을 방지하기 위해 멤버를 숨기는 것을 정보 은폐(Information Hiding)라고 한다. 멤버 선언문에 액세스 지정자를 붙여 공개 범위를 지정한다. 선언하면 바로 사용할 수 있는 일반 변수와 달리 필드는 액세스 지정자에 따라 사용 가능성이 제한된다.

	클래스 내부	패키지 내부	서브클래스	패키지 외부
public	O	O	O	O
protected	O	O	O	서브클래스만
디폴트	O	O	X	X
private	O	X	X	X

선언문의 지정자와 액세스 위치에 따라 공개 여부가 달라진다. 클래스 내부에서는 모든 멤버를 자유롭게 액세스할 수 있다. 자기 자신의 정보이니 마음대로 읽고 쓰는게 당연하다. 공개 범위가 가장 넓은 public 지정자는 어디에서나 액세스를 허가한다. 주로 외부에서 참조하는 멤버를 public으로 지정한다.

반면 가장 높은 은폐 수준인 private 지정자는 외부로 일체의 정보를 공개하지 않는다. 클래스 밖에서 이 멤버를 읽고 쓸 수 없음은 물론이고 심지어 존재도 알려지지 않아 이런 멤버가 있는지도 모른다. 클래스가 내부적으로만 사용하는 꽁꽁 숨겨 놓은 멤버이다.

중간 단계인 protected는 패키지 내부이거나 상속에 의한 자식 클래스만 액세스할 수 있다. 지정자를 생략하면 디폴트가 적용되어 패키지 내부에서는 자유롭게 액세스할 수 있지만 외부에서는 액세스를 금지한다. 지금까지의 예제는 지정자를 붙이지 않아 패키지내에서 공개한 것과 같다. 이 두 지정자에 대해서는 상속과 패키지까지 알아본 후에 다시 연구해 보자.

지금은 public과 private 지정자를 통해 정보 은폐의 필요성과 효과에 대해서만 이해하면 된다. Time 클래스에 액세스 지정자를 적용하여 외부에서 값을 함부로 변경하지 못하도록 방어 코드를 작성해 보자. 필드는 숨기고 이 필드를 액세스하는 메서드만 외부로 공개하여 무의미한 값이 대입되지 않도록 한다.

accessor
class Time { private boolean am; private int hour; private int minute; private int second; Time(int hour, int minute, int second) { setHour(hour); setMinute(minute); setSecond(second); } public int getHour() { return hour; } public void setHour(int hour) { if (hour >=0 && hour <= 23) { this.am = hour < 12; this.hour = hour % 12; if (this.hour == 0) this.hour = 12; } } public int getMinute() { return minute; } public void setMinute(int minute) { if (minute >=0 && minute <= 59) { this.minute = minute; } } public int getSecond() { return second; } public void setSecond(int second) { if (second >=0 && second <= 59) { this.second = second; } } void whatTime() { System.out.print(am ? "오전 ":"오후 "); System.out.println(hour + "시 " + minute + "분 " + second + "초"); } } class JavaTest { public static void main(String[] args) { Time now = new Time(12, 34, 56); now.whatTime(); // now.hour = 34; // 에러 now.setHour(34);; // 거부 now.setSecond(-25); // 거부 now.whatTime(); now.setHour(10);; // 가능 now.setMinute(45); // 가능 now.whatTime(); } }
실행결과	오후 12시 34분 56초 오후 12시 34분 56초 오전 10시 45분 56초

내부의 주요 필드를 private로 지정하여 숨겼으므로 외부에서는 조작할 수 없다. 대신 이 필드를 읽고 쓰는 getter, setter 메서드를 제공하되 이 메서드는 public이다. 숨겨진 필드를 대신 읽고 쓰는 메서드를 액세서(accessor)라고 부른다. 필드는 숨기고 액세서만 공개함으로써 조건에 맞는 값만 받아들인다.

값을 읽는 것은 큰 문제가 되지 않아 getter는 필드값을 리턴하는 식으로 작성한다. 이에 비해 값을 변경하는 setter는 조건을 검사하여 유효한 값만 대입한다. setMinute 메서드는 인수로 전달된 minute 값이 0 ~ 59 범위 안의 유효한 값일 때만 this.minute를 변경하고 그 외의 경우는 무시한다.

hour, second 멤버도 비슷한 방식으로 엉뚱한 값이 들어오지 않도록 방어한다. 생성자도 필드를 직접 대입하지 않고 setter를 호출한다. 생성자는 필드를 직접 조작할 수 있지만 일관된 관리를 위해 값을 변경하는 창구를 일원화하였다. 액세서를 통해서만 값을 변경할 수 있어 객체의 유효성이 항상 보장된다.

main에서 Time 객체 now를 오후 12시 34분 56초로 생성했다. main은 Time 클래스의 외부여서 숨겨진 필드를 직접 액세스할 수 없다. now.hour를 읽거나 쓰면 에러로 처리된다. 대신 setHour 메서드를 호출하여 간접적으로 값을 변경하되 유효한 값만 받아 들인다. setHour(34)를 호출하여 34시로 변경하려 해도 메서드 내부에서 이 값을 거부한다.

setMinute(88)이나 setSecond(-25) 같은 호출문도 아무 효과가 없다. 물론 setHour(10), setMinute(45) 같은 유효한 값은 정상적으로 처리되어 잘 변경된다. 메서드가 정상적인 값만 받아들이므로 객체는 무결성을 유지하며 전체적으로 안정성이 개선된다.

액세서의 원리는 간단하지만 일일이 만들기는 무척 번거롭다. 메서드 이름이 필드 이름과 유사하고 본체에서 하는 일도 거의 비슷한데 매번 입력하기 귀찮다. 이럴 때는 이클립스의 코드 생성 기능이 편리하다. 메뉴에서 Source/Generate Getters and Setters 항목을 선택한다.

액세서로 보호할 필드를 선택하고 OK 버튼을 누르면 메서드의 기본 뼈대를 만들어 준다. hour 필드에 대한 액세서는 다음과 같이 생성된다.

public int getHour() {

return hour;

}

public void setHour(int hour) {

this.hour = hour;

}

읽고 쓰는 기본 코드만 작성해 주는데 여기에 규칙을 추가하여 코딩한다. getter는 웬만해서는 수정할 일이 없고 통상 setter에 조건문이나 부효과 처리를 작성한다.

10-1-2.부효과 처리

액세서는 메서드이므로 임의의 코드를 작성하여 섬세한 조건 점검은 물론 능동적인 동작도 가능하다. 잘못된 값으로부터 필드를 방어할 뿐만 아니라 필드 변경시 같이 조치해야 할 작업까지 처리한다. 값 하나가 변경됨으로써 부차적으로 처리할 작업을 부효과(side effect)라고 하는데 바로 앞 예제의 setHour 메서드가 좋은 예이다.

시간값인 hour 필드가 변경되면 12시 이전인가 이후인가에 따라 am 필드의 값도 같이 조정해야 한다. setHour 메서드는 인수로 전달된 24시간제의 시간을 12시간제로 조정하되 hour가 12시 미만이면 am을 true로 변경하는 추가적인 조치를 수행한다.

또한 자정은 0시라는 표현보다 오전 12시라는 표현이 더 익숙하므로 12로 변경한다. 무효한 값으로부터 필드를 방어할 뿐만 아니라 필드 변경시 수행해야 할 모든 작업을 완벽하게 처리하여 객체의 무결성을 지킨다. 그래서 setHour 메서드로 시간을 변경하면 오전 16시나 오후 0시 따위의 무효한 상태가 되지 않는다.

부효과 처리를 위해 액세서가 다른 필드까지 변경할 필요가 있다. 다음 예제의 Range 클래스는 어떤 범위를 표현한다. 학생의 출석 번호 범위일 수도 있고 텍스트 편집기에서 선택 블록의 오프셋 범위일 수도 있다.

sideeffect
class Range { private int from; private int to; Range(int from, int to) { setFrom(from); setTo(to); } public int getFrom() { return from; } public void setFrom(int from) { this.from = from; if (to < from) { to = from; } } public int getTo() { return to; } public void setTo(int to) { this.to = to; if (from > to) { from = to; } } public void outRange() { System.out.println(from + " ~ " + to); } } class JavaTest { public static void main(String[] args) { Range range = new Range(2, 6); range.outRange(); range.setFrom(8); range.outRange(); } }
실행결과	2 ~ 6 8 ~ 8

시작과 끝 위치인 두 개의 정수 필드 from, to를 선언하고 두 필드값 사이를 범위로 표현한다. 범위란 원론적으로 시작 위치가 끝 위치보다 작거나 같아야 한다. 이 조건이 맞지 않으면 무효하다.

10 ~ 20이나 5 ~ 38은 합당하지만 20 ~ 10이나 9 ~ 1의 범위는 잘못된 것이며 무효한 객체가 어떤 말썽을 일으킬지 예측하기 어렵다. 이 범위를 사용하는 곳에서 다음 코드로 루프를 돌 것이다.

for (int i = from; i < to; i++) { .... }

이 루프가 정상적으로 실행되려면 from이 더 앞쪽이어야 한다. from이 더 크다면 정수형의 최대 범위인 40억번이나 반복되는데 이는 원하는 결과가 아니다. Range 클래스의 set 액세서는 객체가 이런 잘못된 상태가 되지 않도록 부효과를 잘 처리한다.

대표적으로 setFrom 메서드만 분석해 보자. 인수로 받은 from을 from 필드에 일단 대입한다. 그리고 from과 to 필드값을 비교해 보고 from이 더 크다면 to도 from에 맞추어 같이 이동한다. setTo 메서드는 비슷한 원리로 from을 to에 맞춘다. 예제에서는 2 ~ 6까지의 범위를 가지는 객체를 하나 생성한 후 setFrom(8)을 호출해 보았다.

to가 6인 상황에서 from만 8로 변경하면 범위는 8 ~ 6이 되어 무결성이 깨진다. 이를 방지하기 위해 to도 8로 변경하여 길이가 0이더라도 범위의 조건은 최소한 만족하도록 했다. 이 외에도 무결성을 지키는 방법은 여러 가지가 있는데 필요에 따라 선택하면 된다.

to를 강제로 from에 맞추는 대신 from을 to에 맞추는 방법도 생각할 수 있다. 2 ~ 6범위일 때 setFrom(8) 호출문에 대해 to를 8로 바꾸지 않고 from을 to값인 6에 맞추어도 무결성은 지켜진다. 그러나 호출자의 의도를 무시했다는 면에서 앞쪽 방법보다 좋지는 않다. 무효한 값은 아예 무시해 버리거나 아니면 예외를 던져 잘못된 값임을 적극적으로 알리는 방법도 가능하다.

10-1-3.캡슐화의 효과

객체의 안전을 좌우하는 중요한 멤버라면 알아서 건드리지 않으면 될 것을 왜 굳이 문법적인 지정자까지 동원하여 강제적으로 감추는걸까? 이런 강력한 장치가 필요한 이유는 클래스를 만드는 사람과 쓰는 사람이 다르기 때문이다. 객체지향의 주요 목적중 하나는 개발자의 요구 숙련도를 떨어뜨려 누구나 조립할 수 있도록 하여 생산성을 높이는 것이다.

이 목적을 달정하기 위해 캡슐화는 꼭 필요한 안전 장치이다. 하드웨어 조립 방식을 소프트웨어에 적용하기 위해 도입한 것이 객체이다. 객체가 제대로 된 부품이 되려면 하드웨어 부품에 상당하는 안전성이 요구된다. 실제 하드웨어 부품에 비유하여 소프트웨어 부품인 객체가 왜 캡슐화를 잘 해야 하는지 연구해 보자.

1.사용 편의성

캡슐화는 사용자가 굳이 알 필요 없는 정보를 숨겨 난이도를 낮춘다. 마우스는 센서, 버튼, 휠, 무선 송수신부 등의 부품으로 구성되며 내부에는 센서의 정보를 처리하는 CPU와 작업용 메모리도 있다. 사용자는 이 많은 부품이 어떻게 동작하고, 움직임을 어떻게 인식하는지 모르며 심지어 그런 부품이 있는지도 모른다.

사용자가 알고 있는 정보란 움직이면 커서가 이동하고 버튼을 누르면 클릭된다는 것 뿐이다. 센서가 어떤 식으로 방향과 거리를 계산하고 컴퓨터와 통신하는지 몰라도 상관없으며 공개된 조작법(인터페이스)만 알면 된다. 마우스가 정보 은폐를 잘 하고 있어 누구나 부담없이 쓸 수 있다.

센서와 기판이 공개되어 있고 그런 것까지 알아야 쓸 수 있다면 마우스 활용 기사 자격증 같은게 생길지도 모른다. 일상 생활에서 늘상 사용하는 텔레비전, 냉장고, 세탁기도 정보를 적절히 숨기고 꼭 필요한 기능만 공개하여 버튼을 누르는 것만으로 쉽게 활용할 수 있다.

소프트웨어 부품인 객체도 마찬가지다. 사용자가 굳이 몰라도 되는 것은 가급적 숨겨야 하며 안전에 치명적인 핵심 부분은 아예 존재를 드러낼 필요가 없다. 여기서 사용자란 객체를 조립하는 응용 프로그램 개발자를 의미한다. 예를 들어 동영상을 재생하는 클래스가 있다고 하자.

class MoviePlayer {

private 버퍼;

private 헤더;

private 압축 해제();

private 사운드 추출();

private 영상 변환();

....

public load(파일);

public play();

public stop();

}

동영상의 구조는 상상을 초월할 정도로 복잡하다. 코덱도 천차만별이고 압축 알고리즘도 난해하다. 내부적으로 버퍼, 헤더 등의 필드가 있고 압축 해제, 사운드 추출 메서드도 필요하다. 그러나 정작 사용자에게 필요한 것은 복잡한 알고리즘이 아니라 동영상을 재생하는 것 뿐이다. 이 클래스를 사용하는 개발자는 공개된 멤버를 호출하여 원하는 작업을 수행한다.

MoviePlayer mp = new MoviePlayer();

mp.load("연필 부인 흑심 품었네.avi");

mp.play();

동영상 재생 객체를 생성하고 파일을 읽어 재생하면 된다. 영상과 사운드를 어떻게 출력하는지 몰라도 상관없으며 화면에 동영상만 잘 나오면 장땡이다. 이렇게 복잡한 클래스도 최소한의 기능만 공개하여 캡슐화함으로써 사용법은 극단적으로 쉬워진다.

2.안정성

객체를 사용하는 모든 사람이 숙련자는 아니며 생초보도 많다. 객체의 복잡도가 증가하면 사용하기 어렵고 숙련자도 실수할 가능성이 높아진다. 부품은 그 자체로 완벽해야 하며 어디에 어떤 식으로 사용되더라도 자신의 역할을 충실히 잘 수행하며 오동작을 최소화해야 한다.

자동차를 예로 들어 보자. 액셀을 밟으면 연료양을 조절하는 스로틀 밸브가 열리고 엔진 회전수가 높아져 가속된다. 사용자에게 공개된 것은 액셀뿐이며 스로틀 밸브나 엔진은 직접 조작할 수 없도록 숨겨져 있다. 만약 스로틀 밸브가 사용자에게 공개되어 있다면 터무니없이 많은 연료를 쏟아 부어 엔진이 터져 버릴 것이며 이것은 바람직한 공개가 아니다.

엔진이 한 번에 태울 수 있는 양을 초과하는 연료를 주입해서는 안된다. 사용자는 오직 액셀을 통해서만 연료량을 안전하게 조작할 수 있으며 숨겨진 부품은 건드릴 수 없다. 이런 정보 은폐는 합리적이며 누구도 자유를 구속한다고 투덜대지 않는다.

MoviePlayer 클래스의 버퍼나 헤더가 공개되어 있다면 이 정보를 잘못 조작하여 동영상이 재생되지 않거나 다운될 수도 있다. 사용법을 제대로 숙지하지 못한 사용자 과실로 전가하는 것은 무책임하다. 비숙련 사용자가 실수하고 싶어 안달이 났어도 도저히 그럴 수 없도록 철저히 방어해야 한다. 사용자는 오로지 public 멤버를 통해서만 객체를 안전하게 사용할 수 있다.

하드웨어도 약간의 제약을 두어 안정성을 확보하는 예는 흔하다. 대부분의 케이블은 비대칭으로 설계되어 있어 반대로 꽂으면 들어가지 않는다. CPU나 메모리의 핀도 비대칭 구조로 되어 있어 정해진 방향으로 꽂아야 한다. 사용자의 실수까지 고려하여 최악의 상황을 방지한다. 소프트웨어 부품도 안전성을 위해 치명적인 멤버는 반드시 숨겨야 한다.

3.개선 용이성

내부적인 멤버를 숨겨야 하는 또 다른 이유는 기능을 안정적으로 개선하고 사용자의 기존 지식을 최대한 보호하기 위해서이다. 숨겨진 기능은 사용자가 애초에 알지도 못하고 쓰지도 않았으니 자유롭게 업그레이드할 수 있다.

MoviePlayer의 압축 알고리즘을 개선하여 속도가 월등히 빨라졌다고 하자. 사용자는 압축 해제 코드를 직접 호출하지 않았으므로 사용 방법은 여전히 유효하며 기존 코드도 잘 컴파일된다. 다만 빨라진 알고리즘으로 인해 속도만 개선될 뿐이다.

이에 비해 공개된 멤버가 변경되면 사용법이 바뀌어 기존 클래스와 호환되지 않는다. 사용자의 지식은 무효가 되어 다시 배워야 하며 기존 코드도 새 인터페이스에 맞게 수정해야 한다. 공개된 부분을 수정하는 것이 이토록 번거롭기 때문에 애초에 사용자와 직접적인 인터페이스를 이루지 않는 부분은 최대한 숨기는 것이 유리하다.

실생활의 물건도 이 원칙을 지킨다. 마우스는 움직여 커서를 옮기고 버튼을 눌러 클릭하는 사용법만 지키면 나머지는 자유롭게 수정할 수 있다. 볼을 굴리건, 레이저로 감지하건 상관없고 버튼을 스위치로 만들건 터치로 만들건 사용법이 바뀌는 것은 아니다. 정보 은폐를 잘 해 놓았기 때문에 은폐된 부분을 자유롭게 업그레이드할 수 있다.

이 외에도 정보를 숨겨할 할 이유는 많다. 개발자라고 해서 다 같은 수준이 아니다. 클래스 라이브러리는 고도로 숙련된 최상급의 개발자가 만들지만 이 클래스를 사용하는 개발자는 완전 쌩초보일 수도 있다. 실무 개발자도 라이브러리 제작자 입장에서는 비숙련 사용자이므로 헷갈리지 않도록 직관적으로 만들어야 하며 이를 위해 캡슐화를 적극적으로 적용해야 한다.