设计与声明

2023-12-25 21:10:58

设计与声明

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

条款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。

请记住：

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

条款19：设计class犹如设计type

　　C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结......全部在你手上。

　　设计优秀的类是一项艰巨的工作，因为涉及好的类型是一项艰巨的工作。好的类型有自然的语法，直观的语义，以及一或多个高效实现品。

　　设计一个良好的类，或者称作类型，考虑一下设计规范：

新类型的对象应该如何被创建和销毁？
对象的初始化和对象的赋值该有什么样的差别？
新类型的对象如果被passed by value（值传递），意味着什么？
什么是新类型的“合法值”？
你的新类型需要配合某个继承图系吗？
你的新类型需要什么样的转换？
什么样的操作符和函数对此新类型而言是合理的？
什么样的标准函数应该驳回？
谁该取用新类型的成员？
什么是新类型的“未声明接口”？
你的新类型有多少一般化？
你真的需要一个新类型吗？

请记住：

Class的设计就是type的设计。在定义一个新的type之前，请确定你已经考虑过本条款覆盖的所有讨论主题。

条款20：宁以pass-by-reference-to-const替代psss-by-value

　　缺省情况下C++以by value方式传递对象至函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。所以在以对象为by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的形式开销还是比较大的。

　　如果我们用pass-by-reference-to-const，这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。

class Base
{
public:
    string name() const;
    virtual void display const;
};
class Derived:public Base
{
public:
    virtual void display() const;
};
void print(Base b)//(Base& b)
{
    cout<<b.name()<<endl;
    display();
}
//如下调用方式
Derived d;
print(d);//b参数会被构造成一个Base对象，所有派生类对象特化的信息都会被消除

　　以传引用方式传递参数也可以避免对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。

　　所以我们一般的做法应该是这样：内置对象和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。

请记住：

尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。
以上规则并不使用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。

条款21：必须返回对象时，别妄想返回其reference

　　当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。

　　任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么，引用只是个名称，代表某个既有的对象。

函数创建新对象的途径有二：

栈上：即在函数内的局部变量。局部变量在函数返回后就没有存在的意义，所以传引用在栈上不可行。
堆上：在堆上构造一个对象，并返回。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？而且还必须付出一个构造函数的调用代价。别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。

　　可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。

const Rational& operator*(const Rational& a,const Rational& b)
{
    static Rational res;
    res=...
    return res;
}
Rational a,b,c,d;
if((a*b)==(c*d))//恒为true
//等价于下列
if(operator==(operator*(a,b),operator*(c,d)))

　　operator==被要求用operator*内静态对象的值和operator*内静态对象的值来比较，两次operator*调用的确改变了各自静态对象的值，因为他们返回的都是引用，因此调用端永远都是static Rational的“现值”。

　　一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。

请记住：

绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。条款4已经为单线程中合理返回一个reference指向一个local static对象提供一份设计实例。

条款22：将成员变量声明为private

　　其实只有两种访问权限：private（封装）和其他（不封装）。

请记住：

切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允许约束条件获得保护，并提供class作者以充分的实现弹性。
protected并不比public更具封装性。

条款23：宁以non-member、non-friend替换member函数

　　面向对象要求，数据和操作数据的函数应该捆绑在一块，这意味着建议member是更好的选择。

　　面向对象要求数据应该尽可能地封装，因此member比non-memebr带来的封装性更低，因为封装意味着不可看见，越多东西被封装也就是越少的人能够看见，而越少的人能够看见，也就是能最大限度的去改变他们，

　　对象内的数据，越少的代码能够看见他们，越多的数据被封装，我们也就能最大限度的去改变数据。访问数据的函数量作为有多少代码能够看见数据。

　　成员函数不仅可以访问private成员变量，也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性，因为它不能增加访问class之内private成分的函数数量。

　　将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多non-member non-friend函数到此命名空间内。

请记住：

宁可拿non-member non-friend函数替代member函数。这样做可以增加封装性、包裹弹性和机能扩充性

条款24：若所有参数皆需类型转换，请为此采用non-member函数

　　通常，令类支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外，最常见的例外是在建立数值类型时。

const Rational operator*(const Rational& rhs) const;
//如果定义一个有理数类，并实现*操作符为成员函数，如上所示；那么考虑一下调用：
Rational oneHalf(1, 2);
result = oneHalf * 2; // 正确，2被隐式转换为Rational（2，1），伴随一个放进参数列之内的参数
//编译器眼中应该是这样：
const Rational temp(2); 
result = oneHalf * temp;
result = 2 * oneHalf; //构造函数被声明为explicit时，错误，2，可不被认为是Rational对象；因此无法调用operator*，没有一个参数放进参数列之内

　　结论：只有当参数被列于参数列之内，这个参数才是隐式类型转换的合格参与者，低位相当于“被调用之成员函数所隶属的那个对象”——即this对象的那个隐喻参数绝不是隐式转换的合格参与者。

　　所以，支持混合式算术运算的可行之道应该是：让operator*成为一个non-member函数，允许编译器在每一个实参上执行隐式类型转换：

请记住：

如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。

条款25：考虑写出一个不抛异常的swap函数

　　“以指针指向一个对象，内含真正的数据”那种类型，这种设计形式是pimpl。“将隶属对象的数据”从原对象放进另一个对象，然后赋予原对象一个指针，指向那个所谓的实现对象（implementation object）。

class WidgetImpl
{
public:
    //...
private:
    int a,b,c,d,e,f;//数据
    vector<double> v;//意味着可能复制很长时间
};
class Widget
{
public:
    Widget(const Widget& w);
    Widget& operator=(const Widget& w)
    {
        //...
        *pImpl=*(w.pImpl);
        //...
    }
private:
    WidgetImpl* pImpl;
};

　　交换两个widget对象时，只需要交换两个pImpl指针，可以将swap针对widget特化

namespace std//不允许改变命名空间内的任何东西，但是可以为标准template制造特化版本
{
    template<>//全特化
    void swap<Widget>(Widget& a,Widget& b)//这一特化版本是针对T是Widget设计的
    {
        swap(a.pImpl,b.pImpl);//编译不过，pImple是private
    }
}

　　可以令Widget内声明一个swap做真正的置换工作，然后将std::swap特化

class Widget
{
public:
    void swap(Widget& other)
    {
        using std::swap;
        swap(pImpl,other.pImpl);
    }
private:
    WidgetImpl* pImpl;
};
namespace std//不允许改变命名空间内的任何东西，但是可以为标准template制造特化版本
{
    template<>//全特化
    void swap<Widget>(Widget& a,Widget& b)//这一特化版本是针对T是Widget设计的
    {
        a.swap(b);
    }
}

　　C++只允许偏特化template class，不允许function template偏特化，如果打算偏特化function template，我们可以为它添加一个重载版本。

　　客户可以全特化std内的template，但不可以添加新的template（class或function或其他任何东西）到std；

　　还可以使用命名空间

namespace WidgetStuff
{
    ...//模板化的pImple
    template<typename T>
    class Widget{};//同前，内含swap函数
    
    template<typename T>
    void swap(Widget& a,Widget& b)//非成员函数并不属于命名空间
    {
        a.swap(b);
    }
}

　　此时如果你打算交换两个swap，C++会根据名称查找法则找到WidgetStuff内的swap版本。

template<typename T>
void doSomething(T& a,T& b)
{
    using std::swap;//使std内的swap可用
    swap(a,b);
    return ;
}

　　编译器看到对swap的调用，会找到合适的版本。C++名称查找法则：确保找到global作用域或T所在的命名空间内任何T专属的swap，如果T位于WidgetStuff，编译器会使用“实参取决之查找法则”找出WidgetStuff内的swap，如果没有T专属的swap存在，就是用std内的swap（using的存在）。

std::swap(a,b);//error

　　编译器会使用std内的swap（包括其任何template特化），而不再使用一个比较适合的T的专属版本。

　　如果swap的缺省版本对class或template class有可接受的效率就是用他，如果效率不足（意味着class或template使用了pimpl）做以下事

提供一个public swap函数，让他高效的置换你的类型的两个对象的值。
在你的class或template所在的命名空间内提供一个non-member swap，令他调用上述的swap成员函数。
如果你正在编写class而非template class，为你的class特化std::swap，并令他调用你的swap成员函数。

　　如果你调用swap，要包含一个using声明式，以便让std::swap在你的函数内曝光可见。然后不加任何namespace修饰符调用swa。

请记住：

当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。
如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于class（而非templates），也请特化std::swap。
调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。
为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。

码农公寓