정보 은닉이라는 개념은

1971년 데이비드 파나스가 발표했었는데, 이후에

1972년 [On the Criteria To be Used in Decomposing Systems into Modules] 라는 논문이 나옴.

소프트웨어 엔지니어링의 기념비적인 논문이니까 읽어볼만 함.

이는 시스템을 모듈로 분해할때 나누는 기준을 제시한 논문임.

이게 프로그래밍 역사에 매우 중요한 것은 기본적으로

이전에는 처리 단계 즉, 플로우 차트를 그리는 제어 흐름을 기반으로 분해했음.

하지만 이같은 전통적 접근 방법이 높은 결합도(Coupling), 낮은 응집도(Cohesion)을 초래하여 소프트웨어를 유지보수하기 어렵게 만듬.

그래서 이 논문에서 'Information Hiding'이 나옴. 즉 정보 은닉임.

여기서 '모듈'이라는 것을 어떻게 정의 되어야 하는가에 대해서 설명함.

1. 바뀔 가능성이 높은 디자인적 결정에 대해서는 모듈 내부에서 은닉되어야한다.

2. 명확히 정의된 인터페이스만을 통하여 다른 모듈과 통신하여야한다.

즉 각 모듈의 내부 동작 자료 구조, 알고리즘은 외부에서 볼 수 없고, 오로지 공용 인터페이스를 통해서만 상호작용해야한단 것임.

여기서 Parnas는

KWIC 인덱스 시스템을 예시로 잡아서 2가지 분해 방식을 보여줌

1. Input->Ciruclar Shift->Alphabtizing->Output

(입력->변환->정렬->출력 정도로 이해하면됨)

각 모듈이 절차적으로 나누어질 경우 데이터 표현이나 디자인 결정을 바꾸면 여러 모듈에서 수정이 필요해지는 문제가 발생함.

정보은닉 분해

(Information-Hiding)

데이터 저장방법,줄을 어떻게 변형(shift)할지, 정렬을 어떻게 구현할지 디자인 결정 단위로 모듈을 분리함.

내부 구현 및 데이터 형식은 외부에 노출되지 않고, 필요한 기능/데이터만 인터페이스로 제공되는데

어떤 모듈의 자료 구조나 정렬 방법을 바꾸더라도, 인터페이스만 그대로 유지한다면 다른 모듈에는 영향이 거의없음.

결국 모듈이란 무엇인가? 정보 은닉을 중심으로 정의한다면, 다른 프로젝트나 상황에서도 쉽게 재사용할 수 있음.

즉 변경이 모듈 내부에 국한되므로, 프로그램 수정시 오류가 줄고 유지보수가 수월해짐.

안정적인 인터페이스를 유지한 채로, 기능 단위로 정의하면 다른 프로젝트나 상황에서도 쉽게 재사용하거나 수정할 수 있음.

이 논문이 현재 소프트 웨어 엔지니어링의 토대를 만들어낸 논문중 하나로 하고

여기서 절차적 접근에서 구조적 접근으로 바뀐거임.

가끔 이 논문이 OOP를 까는 반박 사례라고 하는데, 이 논문이랑 OOP랑 무슨 연관이 있냐 하는데

OOP는

Public으로 불필요하게 메서드나 필드가 노출되고, 실질적으로 상속으로 인해서 내부 구현이 외부로 들어나서

클래스자체가 정보 은닉이라고 생각하는, 형식적인 캡슐화를 구현했다고해서 OOP가 이 논문을 잘못 해석했다는 비판이 있었음.

즉 클래스를 기능 블록이라고 생각하게 된다면(일반적으로 프갤러들이 주로 말하는)

결국 Panrnas가 지적한 '단계 중심 분해'와 차이가 없게되는거.

즉 일반적으로 한국 책들이나 강사가 소개하는

클래스=데이터+메서드의 단순묶음은 잘못된 접근이고, 형식적인 접근임.

클래스라는 것은 도메인+개념이 책임지는 동작/규칙+필요 인터페이스만 노출된 내부 구현이 이 논문에서 원했던 진정한 정보은닉 이라고 봐야함.

(임의로 요약한거지만 얼추 추상화된 개념들을 요약하면 이럼)

따라서, 잘못쓰여진 OOP는 제대로된 정보은닉을 구현하지 못한거고

이를 극복하고자 상속보다는 컴포지션하라. 라는 말이 나온거.