* 정보 은닉 - 클라이언트는 API의 내부적인 구현 내용을 알아서는 안 된다
* 물리적 은닉 vs 논리적 은닉
물리적 은닉 - private 으로 코드를 선언해서 클라이언트가 코드를 사용할 수 없게 만드는 것
논리적 은닉 - API의 특정 요소에 접근하지 못하도록 언어의 기능을 활용
* 선언 - 단순히 메모리 할당 없이 이름과 타입을 컴파일러에게 알려줌, 함수 프로토타입
extern int i;
class Myclass;
void MyFunc(int value);
* 정의 - 타입의 상세 구조를 제공하고 변수의 경우 메모리를 할당
int i = 0;
class MyClass
{
public:
float x, y, z;
};
void MyFunc(int value)
{
printf("In MyFunc(%d).", value);
}
헤더 파일에 메서드를 선언한 후에 곧바로 정의를 추가할 수 있다
class MyClass
{
public:
void MyMethod()
{
printf("In MyMethod() of MyClass.\n");
}
};
이 방법은 암시적으로 컴파일러가 MyMethod() 라는 멤버 함수를 인라인 형태로 호출할 수 있도록 만든다
그렇기 때문에 API의 설계 관점에서 볼 때 이 방법은 메서드의 구현 코드를 클라이언트에게 노출
직접 인라인 형태로 사용할 수 있기 때문에 좋은 선택 아님
가급적이면 API 헤더는 선언만을 제공
예외 처리되는 규칙
* 물리적 은닉
- 공개된 인터페이스(.h)로부터 분리된 파일(.cpp)에 상세한 내부 로직을 구현
실제 API 개발에서는 인라인 사용을 최대한 자제
* 논리적 은닉 : 캡슐화
- 객체 지향 개념에서 캡슐화는 객체 멤버에 접근을 제한하는 메커니즘 제공
- C++에서 캡슐화는 클래스와 구조체에 대해 아래에 있는 접근 제어 키워드를 사용
- public : 클래스/구조체 멤버는 외부에서 접근이 가능, 구조체의 기본 접근 수준은 public
- protected : 특정 클래스와 파생된 클래스에서만 멤버 접근이 가능
- private : 멤버를 정의한 특정 클래스 내에서만 접근이 가능, 클래스의 기본 접근 수준은 private
- 아마도 여러분이 제공한 API에 대해 클라이언트는 크게 신경쓰지 않는다
- API 사용자는 자신이 원하는 기능 구현하기 위해 API의 내부 코드 사용할 수 있다는 가능성 발견하면 바로 사용
- 사용자는 큰 도움
- 여러분은 해당 코드를 변경해야 할 상황이 발생하면 문제에 부딪히게 되고 결국 제품을 개선하고 최적화 시킬 수 있는 방법 조차 시도 불가
* 캡슐화는 API의 기반이 되는 구현 코드에서 공개 인터페이스를 분리하는 프로세스
* 논리적 은닉
- API의 구체적인 로직이 외부로 노출되지 않도록 C++의 protected와 private 기능을 활용
댓글