조영호 - "오브젝트 : 코드로 이해하는 객체지향 설계" 를 읽고 정리한 글입니다.
객체지향이 익숙하지 않아 글에 미숙함이 있을 수 있습니다. 때문에 지적해 주신다면 감사히 반영하겠습니다.

프로그래머의 역할로 이해해본 캡슐화

객체지향프로그래밍을 공부하다보면 객체가 자율적이어야함, 자율적인 객체가 되려면 캡슐화가 되어야한다는 것을 알 수 있다.
하지만 캡슐화가 왜 필요한지 모르겠고 이해하기 어려워 골머리를 앓던 중에 책에서(p.45) 프로그래머의 역할을 나누고 역할마다 어떻게 객체(클래스)를 이용하는 지 확인함으로써 캡슐화를 이해했고
이것을 공유하고자 글로 남기려고 한다.

역할

• 클래스 작성자
  • 클래스를 작성해서 새로운 데이터 타입을 추가하는 역할이다.
• 클라이언트 프로그래머
  • 클래스 작성자가 추가한 데이터 타입을 사용해서 프로그램을 만드는 역할이다.

두 역할의 교류

클래스 작성자는 클라이언트 프로그래머에게 내부 구현을 노출시키지 않도록 클라이언트 프로그래머에게 필요한 내용만 공개하고(인터페이스) 나머지는 숨긴다. 이것을 구현 은닉이라고 부른다.
이를 언어적인 측면으로 구현하기 위해 public과 private라는 접근자를 사용한다.

• public : 클라이언트가 메시지를 보낼 메서드는 public 접근자를 사용한다.

  • 그 메서드를 사용하기 위해 클라이언트 프로그래머는 클래스의 내부 상태의 존재에 대해서도 몰라도 된다. 인터페이스에 대해서만 알고 있어도 된다.
    (여기서 나는 인터페이스를 자바나 다른 언어에 해당하는 인터페이스라는 도구에 국한해서 생각했다.
    하지만 꼭 그렇지 않고 다른 객체와 협력했을 때 그 객체가 요구하는 행동을 능동적으로 수행하는 책임의 집합, 행동의 집합을 인터페이스라고 이해했다.)

• private :세부적인 구현 내용은 private 영역에 위치시킨다. 그것이 내부 상태이던 메서드이던 private 접근자를 사용한다.

  • 만약 클라이언트 프로그래머가 실수해서 구현 내용을 자기 클래스에 불러드리려고 하면 컴파일은 에러를 던진다.

이렇게 클래스 작성자는 객체를 캡슐화를 시켰으며, 그 결과로 클라이언트 프로그래머는 내부 구현에 손대지 못하게 되었고, 객체가 자율적으로 상태를 바꾸고 행동할 수 있도록 했다.
객체는 능동적으로 상태를 바꾸고 행동을 하기 위해서 다른 객체가 우리 객체의 상태를 헤집어놓는 일은 없어야한다. 이런 일이 없도록 하기 위해 가장 효율적인 도구가 캡슐화인 것이다.

클라이언트 프로그래머가 작성한 객체는 굳이 자기가 안해도 되는 다른 클래스의 내부 구현을 컨트롤하는 일은 이제 안하므로 응집도가 올라갔다.
또한 객체가 다른 인스턴스를 가지고 있다고 해도 은닉을 하게 되어 다른 클래스가 인스턴스를 불러서 사용할 일이 없으므로 의존성이 낮아진다.

추가적으로 내부구현은 자주 "변할 수 있는" 부분이다.
만약 이런 자주 변하는 내부 구현을 클라이언트 프로그래머가 사용하게 한다면 내부 구현이 변하는 만큼 클라이언트 프로그래머가 작성한 객체도 비례해서 변화해야한다.

후기

이런 방식으로 이해가 된 이유는 아무래도 이제껏 배워온 캡슐화에 대한 이론보다 뭔가 현장에서 어떤 식으로 활용하는지, 구체적으로 묘사해서 이해하기 쉬웠던 것 같다.
실제로 내가 경험했던 일과 대조해보면서 이해하려고 노력했다.
객체지향을 이해하려면 실무를 먼저하고 이론을 배우라는 조언이 기억이난다.