Eternity's Chit-Chat

aeternum.egloos.com



Information Hiding Concept & Principle

소프트웨어 설계 시에 고려해야 할 기본 원리 중 가장 중요한 원리가 무엇이냐고 물어 본다면 주저 없이 정보 은닉(Information Hiding)’이라고 대답할 것이다정보 은닉(또는 정보 은폐라고도 한다)은 1972년 Davis Parnas가 발표한 On the Criteria To Be Used in Decomposing Systems Into Modules에 소개된 이후로 오랜 세월 동안 소프트웨어 개발 분야에 지대한 영향을 끼친 원리이다그러나 이런 중요성에도 불구하고 정보 은닉의 개념을 정확하게 이해하고 있는 사람은 많지 않다소프트웨어 개발 분야에서 가장 큰 영향력을 지닌 동시에 가장 큰 오해를 받고 있는 두 가지 원리가 있다면 바로 정보 은닉과 캡슐화(Encapsulation)일 것이다.

 

대부분의 사람들은 외부에서 제공된 공용 메소드를 통해서만 내부 데이터에 접근할 수 있도록 하고 직접적으로 내부 데이터에 접근할 수 없도록 막는 방법을 정보 은닉이라고 알고 있다이것은 정보 은닉과 데이터 캡슐화라는 두 용어 간의 유사성으로 인해 빚어진 오해이다데이터를 공용 메소드를 통해서만 접근하도록 허용하는 방법을 데이터 캡슐화라고 하며 정보 은닉과 데이터 캡슐화는 동일한 개념이 아니다.

 

간단하게 말하자면 정보 은닉은 모듈을 분할하기 위한 기본 원리다.

 

모듈은 서브 프로그램이라기 보다는 책임의 할당이다모듈화는 개별적인 모듈에 대한 작업이 시작되기 전에 정해져야 하는 설계 결정들을 포함한다. … 분할된 모듈은 다른 모듈에 대해 감추어야 하는 설계 결정에 따라 특징지어 진다해당 모듈 내부의 작업을 가능한 적게 노출하는 인터페이스 또는 정의를 선택한다. … 어려운 설계 결정이나 변화할 것 같은 설계 결정들의 목록을 사용해서 설계를 시작할 것을 추천한다이러한 결정이 외부 모듈에 대해 숨겨지도록 각 모듈을 설계해야 한다.

- Davis Parnas, “On the Criteria To Be Used in Decomposing Systems Into Modules

 

정보 은닉은 외부에 감추어야 하는 비밀에 따라 시스템을 분할하는 모듈 분할의 원리이다모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다.

 

시스템의 모듈을 분할하기 위한 설계 원리인 정보 은닉은 변경 가능한 측면을 추상화하는 인터페이스를 사용하여 변경에 대한 세부 내용을 캡슐화하거나 감추고 사용자(이 경우 다른 시스템 모듈 내의 소프트웨어)에게 일반적이고 통합된 서비스 집합을 제공한다이것은 각 모듈이 자신만의 작은 도메인(small domain)으로 구성되어 있음을 의미한다여기에서는 특별한 지식 영역 또는 전문적인 식견을 의미하기 위해 도메인(domain)이라는 용어를 사용한다.

- Len Bass, Paul Clements, Rick Kazman, “Software Architecture in Practice 2nd Edition”

 

모듈은 다음과 같은 두 가지 비밀을 감추어야 한다.

  • 복잡성 : 모듈이 너무 복잡한 경우 이해하고 사용하기가 어렵다외부에 모듈을 추상화시킬 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다. 
  • 변경 가능성 : 변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생할 경우 파급 효과가 커진다변경 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공하도록 한다.

 

정보 은닉은 데이터 캡슐화가 아니다정보 은닉은 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다정보 은닉의 목적은 변경에 대한 유연성을 제공하는 것이다정보 은닉의 원리에 따라 설계된 시스템은 변경에 대한 파급효과가 지역적이기 때문에 변경에 따르는 비용이 상대적으로 적다적절히 모듈화된 코드는 주어진 코드의 일부를 이해하기 위해 필요한 정보의 양이 적기 때문에 코드를 이해하기가 더 쉽다또한 상호 교환해야 하는 정보의 양을 최소화하면서 독자적으로 각 모듈에 대한 작업을 진행할 수 있으므로 개발 기간을 단축시킬 수 있다.


대규모의 소프트웨어를 만들 때 겪는 주요 어려움은 프로그래머들이 다수의 업무를 동시에 진행할 수 있게 일을 나누는 것이다이런 일의 모듈화는 정보 은닉의 개념에 매우 의존적이다정보 은닉은 객체와 알고리즘이 필요하지 않은 시스템 일부에는 가능한 한 이들을 보이지 않게 한다적절히 모듈화된 코드는 시스템의 주어진 일부를 이해하기 위해 필요한 정보의 양을 최소화함으로써 프로그래머가 인지하는 부하를 줄여준다잘 설계된 프로그램에서는 모듈 간의 인터페이스가 가능한 좁으며(간단하며)” 변경될 수 있는 설계적 결정 사항은 하나의 모듈에 숨겨진다여기서 모듈에 숨겨져 있다는 것이 중요한데대부분의 상용 소프트웨어는 처음의 개발보다 유지보수(오류 수정과 개선)에 들어가는 프로그래머의 시간이 훨씬 더 많기 때문이다.

- Michael L. Scott, “다시 보는 프로그래밍 언어

 

정보 은닉의 가장 큰 힘은 자기 유사성이다시스템을 구성하는 작은 단위의 함수부터이벤트 기반 아키텍처의 한 구성 요소인 시스템에 이르기까지 모든 요소를 설계하기 위한 원리로 적용이 가능하다자기 유사성이라는 정보 은닉의 장점은 다양한 프로그래밍 패러다임의 변화를 주도해 왔으며 현재 주도적인 패러다임의 위치를 차지하고 있는 객체 지향 프로그래밍은 정보 은닉을 효율적으로 적용할 수 있는 메커니즘인 클래스를 언어 차원에서 제공한다.

 

Parnas의 모듈에 대한 정보 은닉 정의는 매우 중요한 연구 프로그램에서 공개적으로 내디딘 첫 발걸음이며객체 지향 프로그래밍의 지적인 조상이다그는 모듈을 자체 데이터 모델과 자체 작동 집합을 가진 소프트웨어 실체라고 정의했다모듈의 데이터에는 그 모듈의 적절한 작동들 가운데 하나를 통해서만 접근할 수 있다두 번째 발걸음은 여러 사상가들의 헌신으로 이루어졌다그들이 Parnas의 모듈을 추상 데이터 타입(Abstract Data Type)으로 업그레이드하였기에그것으로부터 수많은 객체들이 도출될 수 있었다추상 데이터 타입은 모듈 인터페이스에 대한 일관된 사고와 명시 그리고 시행하기 쉬운 액세스 기율 등을 제공한다.

세 번째로 내디딘 발걸음은 객체 지향 프로그래밍으로상속이라는 강력한 개념이 처음으로 도입되었고그에 따라 클래스들(데이터 타입들)은 클래스 계층 속의 조상들로부터 지정된 속성들을 기본적으로 갖게 된다우리가 객체 지향 프로그램에서 얻고자 하는 대부분은 사실상 Parnas가 내디딘 첫 발걸음에서즉 모듈의 캡슐화여기에 덧붙여 재사용을 목표로 설계되고 테스트된 모듈이나 클래스로 이뤄진 사전 구축된 라이브러리라는 아이디어에서 비롯된 것이다.

- Frederick P. Brooks, Jr. “맨먼스 미신, 20주년 기념판

 

정보 은닉은 구조적인 설계와 객체 지향적인 설계 모두에 있어서 기본적인 구조이다구조적인 설계에서는 블랙박스라는 개념이 정보 은닉으로부터 왔다객체 지향적인 설계에서는 정보 은닉이 캡슐화와 모듈화를 발생케 하였으며추상화 개념과 연결된다.

- Steve McConnell, "Code Complete 2nd Edition"


그렇다면 정보 은닉과 캡슐화의 차이는 무엇일까대부분의 사람들은 캡슐화를 데이터를 공용 메소드로 감추는 방법또는 관련된 데이터와 함수를 하나의 단위로 묶는 방법이라고 생각한다전자는 캡슐화의 한 종류인 데이터 캡슐화를 의미하며후자는 추상 데이터 타입(ADT)-책임 할당의 개념으로 보면 INFORMATION EXPERT 패턴-의 개념이다그러나 이런 관점은 캡슐화의 한 단면만을 이야기할 뿐이다.

 

캡슐화는 온갖 방법의 숨기기라고 생각하면 쉽다캡슐화를 통해 데이터를 숨길 수 있다그리고 구현 코드파생 클래스 또는 여러 가지의 것들을 숨길 수 있다. … 따라서실제로 어떠한 종류의 파생 클래스가 나타나는지를 알고 있는 클라이언트를 가지지 않으면서 다형적으로 행위하는 추상 클래스가 존재할 때 이러한 캡슐화가 이루어질 수 있다.

- 알란 섈로웨이제임스 트로트, “알기 쉬운 디자인 패턴

 

이러한 다양한 방법의 숨기기를 통해 클래스클래스 그룹또는 패키지 전체에 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다.

 

설계에서 무엇이 변화될 수 있는지 고려하자. 이 접근법은 재설계의 원인에 초점을 맞추는 것과 반대되는 것이다설계에 변경을 강요하는 것이 무엇인지에 대해 고려하기보다는재설계 없이 변경시킬 수 있는 것이 무엇인지 고려하자여기에서의 초점은 많은 디자인 패턴의 주제인 변화하는 개념을 캡슐화하는 것이다.

- GOF, “디자인 패턴

 

대부분의 컨텍스트에서 캡슐화와 정보 은닉은 동일한 의미를 지니다복잡한 설계 결정또는 변경이 발생할 수 있는 설계 결정을 안정적인 인터페이스 배후로 감추는 것이다따라서 캡슐화와 정보 은닉의 차이점에 대해 고민하기 보다는 원리를 충족시키는 방법에 초점을 맞추는 것이 올바른 접근방법이다.

 

정보 은닉과 캡슐화가 전해주는 만트라는 변경에 대비하여 설계를 하라는 것이다이것은 Craig Larman이 “UML과 패턴의 적용에서 제시한 PROTECTED VARIATION 패턴과 동일하며객체 지향 분석/설계 영역에서 이를 달성하기 위한 가장 훌륭한 방법은 OCP(Open-Closed Principle) 원리를 따르는 것이다. OCP에 대한 자세한 논의는 Rober C. Martin의 저서인 소프트웨어 개발의 지혜에서 자세히 다루고 있다.

 

그러나 변경에 대비하는 설계가 항상 좋은 것은 아니다변경은 실제로 변경이 발생할 때에만 그 의미가 있다불필요한 복잡성(Needless Complexity)의 문제는 개발자가 요구 사항에 대한 변경 내용을 막연히 예상하고 잠재적인 변경을 처리할 수 있는 불필요한 코드를 넣었을 때 발생한다이것은 XP의 슬로건인 “YAGNI(You Aren’t Gonna Need It)”와도 연관이 있다. YAGNI는 지금 당장 그 기능이 필요하지 않다면 정말 필요해질 때까지 해당 기능을 구현하지 말라는 의미다.

 

이렇게 하는  번째 이유는 경제적인  때문이다만약 내일 필요하게  기능을 위해 작업해야 한다면이번 반복동안에 개발되어야  기능에 쏟을 노력이 손실된다는 것을 의미한다릴리즈 계획은 지금 해야 하는 작업에 관한 것이고 미래를 위해 다른 일을 한다는 것은 개발자와 고객간의 합의에 반하는 것이다. … 이런 경제적인 불이익은 우리가 불필요한 것을 추가할 수도 있다는 가능성 때문에 더욱 커진다.

- Martin Fowler, “Is Design Dead?”

 

그렇다면 정보 은닉과 캡슐화의 원리를 지키면서 변경에 따르는 비용을 최소화하기 위한 방법은 무엇일까변경이 발생할 가능성이 높다면 변경에 대비하기 위한 설계를 하자만약 변경의 발생 여부가 명확하지 않다면 실제로 변경이 발생할 때까지는 그 사실을 잊도록 하자변경이 발생할 경우 리팩토링에 따른 위험성을 낮추기 위해 테스트 케이스라는 안전망으로 코드를 보호하자그리고 변경될 것이라면 최대한 빨리 변경이 발생하도록 촉진시키기 위해 다음과 같은 방법을 사용하자

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


핑백

  • 2016.03.21 – Estel Castle 2016-03-21 15:18:39 #

    ... Uncategorized 2016.03.21 March 21, 2016 pikanpieLeave a comment 캡슐화와 정보은닉 차이: http://aeternum.egloos.com/1232020 react-vis: https://github.com/uber-common/react-vis Demo: http://uber-com ... more