함수도 인터페이스,클래스도 인터페이스,템플릿 또한 인터페이스요....
사용자가 의도한 대로 동작하지 않는다면 그 코드는 컴파일 되어야 하지 않는 것이 맞다.
또한, 어떤 코드가 컴파일된다면... 사용자가 원하는 대로 동작해야한다.

'제대로 쓰기는 쉬우나 엉터리로 쓰기엔 어려운'  인터페이스를 개발하려면 우선 사용자가 저지를 만한 실수를 머리에 넣어 두고 있어야 한다.

예를 들면, 날짜를 저장하는 클래스의 생성자를 설계해보자

class Date{
public:
 Date(int month, int day, int year);
 ...
 };

여기엔 사용자가 저지를 만한 실수가 있다!

매개변수의 전달 순서를 잘못쓰거나,유효 범위를 넘어서는 숫자가 들어갈 수 있다.
1. Date date(30,3,1999) 

->month랑 day를 바꿔서 넣은 경우

2. Data date(3,40,1999)

->day에 유효범위 숫자를 넘어선 녀석을 넣을 경우 

 

이렇듯 사용자의 실수를 방지하기 위한 방법으로는 아래와 같은 방법들이 있다.

  • 새로운 타입 만들기
  • 타입에 대한 연산을 제한하기 
  • 객체의 값에 대해 제약걸기
  • 자원 관리 작업을 사용자 책임으로놓지 않기 

 

 새로운 타입 만들기 

Struct Day
{
	explicit Day(int d):val(d){}
	int val;
};

Struct Month
{
	explicit Month(int m):val(m){}
	int val;
};

Struct Year
{
	explicit Year(int y):val(y){}
	int val;
};

class Date{
public:
	Date(const Month& m , const Day& d , const Year& y);
    ...
 }

각 타입에 제약값을 설정하면 된다.

enum을 쓰는방법도 있지만, 타입안정성은 별로기때문에,,,,, 유효한 Month(or Day or Year...)의 집합을 정의하는게 나을지도~

 

 타입에 대한 연산을 제한하기 

아주~ 흔히 쓰이는 예로는 const를 붙인다. operator*의 반환 타입을 const로 한정함으로써 사용자가 사용자 정의 타입에 대해 실수를 저지르지 않을 수 있었지

 

 

자원 관리 작업을 사용자 책임으로놓지 않기 

  • 사용자 쪽에서 뭔가를 외워야 제대로 쓸 수 있는 인터페이스는 잘못 쓰기 쉽다. 언제라도 잊어버릴수 있기 때문에, 따라서 스마트포인터에게 떠넘겨버리는게 좋다..
  • tr1::shared_ptr는 사용자 정의 삭제자를 지원한다. 이 특징때문에 교차 DLL문제를 막아주며, 뮤텍스등을 자동으로 잠금해제하는데 쓸 수 있다.

 

인터페이스의 올바른 사용을 이끄는 방법

  • 인터페이스 사이의 일관성 잡아주기
  • 기본 제공 타입과의 동작 호환성 유지하기
복사했습니다!