设计与声明

Posted 2020-11-25 tianzeng

　　所谓软件设计，是“令软件做出你希望它做的事情”的步骤和做法，通常以颇为一般性的构想开始，最终变成十足的细节，以允许特殊接口的开发。

条款18：让接口容易被正确使用，不易被误用

　　许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上，类型系统是你的主要同盟国。

class Date
{
public:
    Date(int month,int day,int year);
};
Date(30,2,1997)//应该是2,30

//导入新类型防止接口被误用
struct Day
{
    explicit Day(int d):val(d) {}     //explicit 避免隐式的转换。
    int val;
};
struct Month
{
    explicit Month(int d):val(d) {}     //explicit 避免隐式的转换。
    int val;
};
struct Year
{
    explicit Year(int d):val(d) {}     //explicit 避免隐式的转换。
    int val;
};
class Date
{
public:
    Date(const Month& m,const Day& d,const Year& y);
};
Date(Month(3),Day(30),Year(1997));

//可以用enum来表示月份，但是enum不具备我们希望拥有的安全类型
class Month
{
public:
    static Month Jan(){return Month(1)};
    //...
private:
    explicit Month(int m);
};
Date d(Month::Jan(),Day(30),Year(1997));

　　不能用对象替换为函数，表示某个月份，因为non-local static对象初始化次序可能存在问题。

　　除非有好的理由，否则应该尽量令你的类型（定义的类）的行为与内置类型一致

　　在资源管理方面，也许我们应该“先发制人”，即让函数返回一个资源的指针改为返回一个智能指针。

     std::tr1::shared_ptr<Investment> createInvestment();

　　这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。

　　tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时被调用的“删除器”。但我们自己制定第二个参数，当然这是安全的。但是留给客户，那也许存在危险。

std::tr1::shared_ptr<Investment>//tr1::shared_ptr构造函数坚持第一个参数必须是个指针。
pInv(static_cast<Investment*>(0), getRidOfInvestment);

　　tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。

请记住：

1. 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
2. “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
3. “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
4. tr1::shared_ptr支持定制删除器。这可防范DLL问题，可被用来自动解除互斥量等等。