항목 18: 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자.

인터페이스 설계란 무엇을 말하는 것일까?
클래스의 접근 권한을 이야기 하는것이 아닌, 클래스나 함수, 템플릿의 사용 환경을 말하는것이다.


그렇다면, 엉터리로 쓰게인 어렵게 하자는 말이 도데체 무슨 말일까?
void f(int a, int b) 라는 함수가 있다고 치면, 이 두개의 int형은 서로 다른 속성이 있을 것이다. 그런데 사용하는 입장에선 엉터리로 1번째 매개변수 자리에 2번재 매개변수를 넣어도, 함수는 그 데이터 그대로 받아들여, 원하는 연산을 해주지 않게 된다! 그래서, 햇갈려 하는 함수에는 int형이 아닌, 속성을 가진 int형을 넣어 버리면, 제대로 쓰기엔 쉽게 되고 엉터리로 쓰기엔 어렵게 된다!(값을 넣을때 형 변환을... ㅋㅋㅋ)



이런 마인드로 동적 메모리로 할당한 객체의 참조자를 리턴하는 함수가 있다면 리턴값을 RAII객체에 담으려 하지 말고, RAII 객체로 리턴해 버리면, 사용자 입장에선 제대로 사용하기엔 쉽고, 엉터리로 쓰기엔 어렵게 된다!



이것만은 잊지 말자!
1. 좋은 인터페이스를 만들려면 제대로 쓰기엔 쉽고, 엉터리로 쓰기엔 어렵게 만들자!
2. 사용자 실수를 방지하려면, 속성이 부여된 데이터를 사용하자(,, 새로운 타입을 만들어서 쓰라는 뜼)
3. std::tr1::shared_ptr 은 교차 DELL 문제를 막아 주며, 뮤텍스 등을 자동으로 잠금 해제하는데 쓸수 있도록, 소멸자를 지정해서 쓸수 있습니다.(이 방법은 참 좋은것 같다. 써먹어보자!)


증명 코드
이런 함수 보다는

int date(int year, int month, int day)
{
    // 1달은 30일이라는데에 큰 신경쓰는 사람이 없길 바란다.... ....
    return (year * 365) + (month * 30) + day;
}

이렇게 쓰는게 더 좋다

struct Year
{  
    int m_year;
    explicit Year(int year)
        : m_year(year) {}
};

struct Month
{  
    int m_month;
    explicit Month(int month)
        : m_month(month) {}
};

struct Day
{  
    int m_day;
    explicit Day(int day)
        : m_day(day) {}
};

int date(const Year& y, const Month& m,    const Day& d)
{
    return (y.m_year * 365) + (m.m_month * 30) + d.m_day;
}

그런데 말이 이렇지, 습관화 시키면 편할듯... 제일 좋은건 컴파일 타임에 에러를 만들수 있다는 것이니까.

관련링크
http://redinlife.egloos.com/1615796
2판 : 항목 46. 실행시간 에러보다는 컴파일 시간과 링크 시간 에러가 좋다