캡슐화(Encapsulation)와 정보은닉(Information Hiding)의 차이에 대해서 설명하는 글들을 찾아봤는데, 의외로 명확하게 설명해주는 것들이 없었다. 아래의 링크는 찾아봤던 것들 중에서 둘 간의 차이를 가장 잘 설명해주는 글이다. 해당 글에 나온 2가지 인용구 및 1개의 간단한 예제와 함께 개인적인 생각들을 정리하도록 한다.

The Difference Between Encapsulation and Information Hiding

캡슐화 (Encapsulation)

‘Meilir Page-Jones’는 자신의 책인 Fundamental Of Object Oriented Design in UML에서 캡슐화를 다음과 같이 정의하였다.

Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name.

캡슐화는 관련있는 개념들을 한 곳에 무리짓는 것이라고 한다. 그리고 이 무리는 단일 이름으로 불릴 수 있어야 한다고 한다.

여기서 단일 이름(A SINGLE NAME)이라는 단어가 등장하는데, 부족한 이해를 돕는 참 좋은 키워드라는 생각이 든다. 이는 캡슐화가 잘 되었는지 하나의 지표로 볼 수 있겠다. 만약 이름 짓기가 모호하거나 이름이 잘 표현해내지 못하는 행위(API)가 있다면 이는 캡슐화가 잘 안되었을 수도 있는 일종의 냄새가 되는 것이다.

또 여기서 한 곳(ONE UNIT) 이라는 단어도 언급된다. 이는 클래스를 가리킬 수도 있고, 메서드를 가리킬 수도 있다. 만약 메서드가 캡슐화가 잘 되지 않았다면 하나의 행위를 표현하기 위한 코드들이 두 곳 이상 흩어져 있다는 이야기이다. 이런 경우 관련 있는 코드들을 다시 한 곳에 모아두려는 노력이 필요하며, 이렇게 되면 클라이언트 입장에서는 어떤 행위가 필요할 때 특정 객체의 API만 알고 있으면 된다. 한편, 클래스가 잘 캡슐화 되지 않았다면, 특정 행위가 필요할 때 당최 어떤 클래스에서 찾아야 할지 난감하게 될 것이다.

정보 은닉 (Information Hiding)

이 용어는 무려 40년 전에, ‘Parnas’에 의해 소개(On the Criteria to Be Used in Decomposing Systems Into Modules) 되었다고 한다.

Its interface or definition was chosen to reveal as little as possible about its inner workings.

‘Its’라는 부분이 정확히 무엇을 가리키는지는 좀 더 살펴봐야 알겠지만, 정보 은닉에 대한 개념은 이미 언급 – ‘내부의 동작을 외부로부터 최대한 숨기는 것’ – 되었다. 이렇게 세부 사항을 최대한 숨김으로써 변경 사항이 생겼을 때 우리는 그 영향 범위를 최소화 할 수 있다.

둘 간의 차이

캡슐화와 정보 은닉에 대한 차이는 어느 정도 얘기된 것 같다. 개인적인 판단으로 둘 간의 차이를 조금 더 명시해 보자면 다음과 같다.

  1. 캡슐화: 무리 짓기(Grouping)에 관한 이야기이다. 모듈화가 떠오르기도. 이는 우리가 어떤 행위를 추적(Tracing)하기 쉽도록 도와주며, 예상치 못한 의존성(Unpredictable Dependency)을 제어할 수 있도록 도와준다.

  2. 정보은닉: 추상화(Abstraction)에 관한 이야기이다. 외부에서 알 필요 없는 세부사항을 숨김으로써, 불필요한 의존성(Unnecessary Dependency)를 줄이도록 도와준다.

예제 코드

위에서 링크를 걸어둔 글에서는 클린 코드에 나온 예제를 들어 두 개념을 설명한다. 예제 자체는 기억 나는데 이것이 캡슐화와 정보은닉을 설명된 것인지는 기억 나지 않는다. (다시 봐야 하나..)

먼저 첫 번째 예제는 정보 은닉은 되지 않았지만, 캡슐화는 되어 있는 코드이다. 좌표를 표현하기 위한 개념인 x와 y를 모아두었지만, 이것이 외부에게 노출되어 있다.

public class Point {
    public double x;
    public double y;
}

두 번째 예제는 이렇게 잘 모아진 개념을 적절하게 숨겼고, x와 y좌표를 잘못 사용할 수 있는 가능성을 줄였으며, 어떻게 사용하는지 이해하기 쉽게 가독성을 높인 예제이다.

public interface Point {
    double GetX();
    double GetY();
    void SetCartesian(double x, double y);
    double GetR();
    double GetTheta();
    void SetPolar(double r, double theta);
}

그래서?

사실 둘의 개념은 꼭 구분해서 알아야 할 필요가 있나 싶다. 둘의 차이를 알기 전과 알고 난 후의 설계와 코드는 동일할 것 같기 때문이다. 분명히 다른 개념인 동시에 매우 밀접한 관계이기도 해서, 단지 궁금해서 찾아본 내용일 뿐이다. 다만, 의사소통 할 때 좀 편할 경우가 있을까 싶긴 하다.

캡슐화에 관한 정의들을 소개하는 것으로 글은 마무리.

It […] refers to building a capsule, in the case a conceptual barrier, around some collection of things. — [Wirfs-Brock et al, 1990]

As a process, encapsulation means the act of enclosing one or more items within a […] container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items.

If encapsulation was ‘the same thing as information hiding,’ then one might make the argument that ‘everything that was encapsulated was also hidden.’ This is not obviously not true.