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

제대로 쓰기엔 쉽고 엉터리로 쓰기에 어려운 인터페이스를 개발하려면 우선 사용자가 저지를 만한 실수의

종류를 머리에 넣어두고 있어야 한다.

 

예시 1

 

아래 예는 날짜를 나타내는 어떤 클래스에 넣을 생성자를 설계하는 과정이다.

 

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

 

문제점

 

 - 매개 변수의 전달 순서가 잘못될 여지가 있다.

Date d(30, 3 , 2017); //월에 30이라는 값이 들어가짐

 

 - 월과 일에 해당하는 숫자가 잘못된 숫자일 수도 있다.

Date d(3, 40 , 2017); //3월 40일이라는 값이 들어가짐.

 

 

개선 1-1

 

새로운 타입을 들여와 인터페이스를 강화하면 사용자의 실수를 막을 수 있다.

 

struct Day
{
    explicit Day(int d) : val(d) {    }
 
    int val;
};
 
struct Month
{
    explicit Month(int dm) : 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);
    ...
};
 
Date d(3, 30, 2017);                    //타입이 틀려서 에러 발생.
 
Date d(Day(30), Month(3), Year(2017));  //타입이 틀려서 에러 발생.
 
Date d(Month(3), Day(30), Year(2017));  //정상 컴파일.

 

 

개선 1-2

 

'월'이 가질 수 있는 유효한 값을 검사해야 하는데 enum을 사용해도 되지만 타입 안정성은 그리 믿음직하지 못하다.

타입 안정성이 신경 쓰인다면 유효한 Month의 집합을 미리 정의해 두어도 좋다.

 

class Month
{
public:
    static Month Jan() { return Month(1);  }
    static Month Feb() { return Month(2);  }
    static Month Mar() { return Month(2);  }
    ...
    static Month Dec() { return Month(12); }
 
private:
    explicit Month(int m);    //Month 값이 외부에서 생성되지 못하도록
                              //생성자를 private으로 선언.
};
 
Date d(Month::Mar(), Day(30), Year(2017));

 

여기서 귀찮게 하나 하나 함수로 return하는 식으로 프로그램이 되어 있다.

아래와 같이 편하게 정적 객체로 사용할 수도 있는데.. 그러지 않은 이유는....

 

class Month
{
public:
    static int Jan = 1;
    static int Feb = 2;
    static int Mar = 3;
    ...
    static int Dec = 12;
};

 

항목4에서 배운 '비지역 정적 객체들의 초기화 순서는 정해지지 않는다'는 특성 때문이다.

 

 

예시 2

 

예상되는 사용자 실수를 막는 다른 방법으로는 어떤 타입이 제약을 부여하여 그 타입을 통해 할 수 있는 일들을

묶어 버리는 방법이 있다.

제약 부여 방법으로 아주 흔히 쓰이는 예가 'const 붙이기'이다. 항목3에서 설명했듯이 operator*의 반환 타입을

const로 한정함으로서 사용자가 사용자 정의 타입에 대해 다음과 같은 실수를 저지르지 않도록 할 수 있었다.

 

if ( (a * b) = c ) // 비교하려고 했으나 a*b 에 c를 대입해 버린 코드.

 

여기서 하고자 하는 얘기는 '별다른 이유가 없다면 사용자 정의 타입은 기본 제공 타입처럼 동작하게 만들어라'

라는 것이다. int 등의 타입 정도는 사용자들이 그 성질을 이미 다 알고 있기 때문에, 사용자를 위해 만드는 타입도

웬만하면 이들과 똑같이 동작하게 만들라는 것이다.

 

기본제공 타입과 쓸데없이 어긋나는 동작을 피하는 실질적인 이유는 일관성 있는 인터페이스를 제공하기 위해서이다.

제대로 쓰기에 괜찮은 인터페이스를 만들어주는 요인 중에 중요한 것은 일관성이다.

또한 불편한 인터페이스를 만들어주는 요인 중에 비일관성을 따라오는 것도 거의 없다.

 

사용자 쪽에서 뭔가를 외워야 제대로 쓸 수 있는 인터페이스는 잘 못 쓰기 쉽고 언제라도 잊어버릴 수 있다.

 

 

예시 3

 

항목 13에서 썼던 팩토리 함수를 한 번 보자.

 

Investment* createInvestment();