정보 은닉과 데이터 캡슐화는 동일한 개념이 아니다

정보 은닉

• 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다.
• 외부에 감추어야 하는 비밀에 따라 시스템을 분할하는 모듈 분할의 원리이다.
  • 모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다.
• 정보 은닉의 목적은 변경에 대한 유연성을 제공하는 것이다.

캡슐화

• 데이터를 공용 메소드를 통해서만 접근하도록 허용하는 방법
• '온갖 방법의 숨기기'라고 생각하면 쉽다.
• 캡슐화를 통해 데이터를 숨길 수 있다. 그리고 구현 코드, 파생 클래스 또는 여러 가지의 것들을 숨길 수 있다.
• 다양한 방법의 숨기기를 통해 클래스, 클래스 그룹, 또는 패키지 전체에 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다.

캡슐화와 정보 은닉의 차이점에 대해 고민하기 보다는 원리를 충족시키는 방법에 초점을 맞추는 것이 올바른 접근방법이다.

정보 은닉의 장점

• 정보 은닉의 원리에 따라 설계된 시스템은 변경에 대한 파급효과가 지역적이기 때문에 변경에 따르는 비용이 상대적으로 적다.
• 적절히 모듈화된 코드는 주어진 코드의 일부를 이해하기 위해 필요한 정보의 양이 적기 때문에 코드를 이해하기가 더 쉽다.
• 상호 교환해야 하는 정보의 양을 최소화하면서 독자적으로 각 모듈에 대한 작업을 진행할 수 있으므로 개발 기간을 단축시킬 수 있다.

정보 은닉과 캡슐화의 원리를 지키면서 변경에 따르는 비용을 최소화하기 위한 방법

• 변경이 발생할 가능성이 높다면 변경에 대비하기 위한 설계를 하자.
• 만약 변경의 발생 여부가 명확하지 않다면 실제로 변경이 발생할 때까지는 그 사실을 잊도록 하자. (불필요한 복잡성)
• 변경이 발생할 경우 리팩토링에 따른 위험성을 낮추기 위해 테스트 케이스라는 안전망으로 코드를 보호하자.

불필요한 복잡성(Needless Complexity)의 문제

• 개발자가 요구 사항에 대한 변경 내용을 막연히 예상하고 잠재적인 변경을 처리할 수 있는 불필요한 코드를 넣었을 때 발생한다.
• 지금 당장 그 기능이 필요하지 않다면 정말 필요해질 때까지 해당 기능을 구현하지 말라.

변경될 것에 최대한 빨리 변경이 발생하도록 촉진시키기 위한 방법

• 테스트를 먼저 작성한다.
  • 테스트는 시스템을 사용하는 방법 중 하나이다.
  • 테스트를 먼저 작성함으로써, 시스템을 테스트 가능한 것으로 만들 수 있다.
  • 따라서 테스트 가능한 변경이 일어날 것이고 우리는 테스트 가능한 변경에 대해서는 놀라지 않는다.
  • 그 때쯤이면 시스템을 테스트 가능하게 만드는 추상화를 만들었을 것이다. 우리는 나중에 일어날 다른 종류의 변경에 대해 보호하는 추상화 중 많은 것을 알아차릴 수 있을 것이다.
• 주 단위보다는 일 단위로, 아주 짧은 주기로 개발한다.
• 기반 구조 보다 기능 요소를 먼저 개발하고, 자주 이 기능 요소를 이해당사자에게 보인다.
• 가장 중요한 기능 요소를 먼저 개발한다.
• 소프트웨어를 빨리, 그리고 자주 릴리즈한다. 가능한 빠르게, 자주 고객과 사용자 앞에서 그것을 시연한다.

출처

• http://aeternum.egloos.com/page/100 - Information Hiding