목표

  • 정보 은닉화(Information Hiding)에 대해 알아보자.

정보 은닉의 추상화

정보 은닉화(Information Hiding)

  • 정보 은닉(혹은 정보 은폐)이란 외부에서 감추어야 하는 비밀에 따라 시스템을 분할하는 모듈 분할의 원리이다.
  • 개인적으로 상속, 추상화, 캡슐화, 다형성 같은건 시스템을 설계하기 위한 도구이고, 최종적으로 어떻게 모듈을 분할 시킬 것인가에 대한 정보 은닉이 가장 중요하다고 생각한다.
  • 변경될 가능성이 있는 구현은 감추고, 잘 정의되고 쉽게 변경이 되지 않는 부분은 외부로 공개하여, 내부에 접근하지 못하게 한다.
  • 이때 내부 구현은 추상화하여, 변경에 대한 내용을 캡슐화 하거나 감춰 사용자에게 통합된 인터페이스를 제공할 수 있다.

정보 은닉의 예시

  • 결제 모듈을 개발한다고 생각해보자. 결제 모듈은 Google, OneStore, GalaxyStore, AppleStore 등등이 존재할 수 있다.
  • 이들은 각각 스토어별 Purchase Client Library가 존재할 것이다.
  • 그럼 각 스토어별 인터페이스를 사용자에게 제공할 것인가?
    • PurchaseWithGoogle, PurchaseWithOneStore .. ?
    • 하지만 현실에서는 요청사항이라는 명분으로 빈번하게 일어나는 현상입니다.
  • 사용자가 필요로 하는 인터페이스는 다음 4가지로 정의할 수 있을 것이다.
    • QueryProducts(상품 목록 조회)
    • Purchase(구매)
    • QueryPurchases(구매 목록 확인)
    • ConsumePurchase(소비)
  • 그럼 사용자에게 쉽게 변경되지 않을 4개의 공통 인터페이스를 제공할 수 있게된다.
  • 스토어 별 구현은, 각 스토어 정책에 따라 구현 내용이 다르고 쉽게 변할 수 있다.
    • 이 부분은 추상화 하거나 내부로 감춰 사용자는 몰라도 되게 한다.
    • 예를 들어 구글은 상품 구매를 위해 가격, 상품 설명, 상품 정보, 상품 이름, 상품 아이디가 포함된 객체를 요구한다.
      • 왜 이렇게 많은 정보를 요구하는지 모르겠다.
    • 하지만 OneStore의 경우 상품 아이디만 있으면 된다.
      • 왜 이따구로 만들었는지 모르
    • 구매 부분을 추상화 하면 사용자는 구매 함수에 상품 아이디만 입력하면 두 스토어를 동일하게 이용할 수 있다.
    • OneStore의 경우, 구매가 호출되면 바로 상품 아이디를 받아 구매를 진행하면 될 것이다.
    • 구글의 경우, 상품 아이디를 사용하여 상품 정보를 갱신한 뒤 구매를 진행하면 될 것이다.
    • 하지만 이 과정은 내부 동작으로 사용자에게 알릴 필요가 있다.

비고

  • 구글에 정보 은닉을 검색하면, 아래와 같은 글들이 많이 보인다.

    • "private, public으로 변수 접근 제어를 막는것"
    • "getter, setter로 변수에 접근을 통일하는것"
  • 이건 캡슐화 방법이지 정보 은닉 개념이 아니다.

  • 정확한 내용은 아래 원문을 확인해보자.

    • Davis Parnas, "On the Criteria To Be Used in Decomposing Systems Into Modules"
  • 참고문헌 : http://egloos.zum.com/aeternum/v/1232020

+ Recent posts