Effective C++ 总结(二)

四.设计与声明
    

     条款18:让接口容易被正确使用,不易被误用

     理想上,如果客户企图使用某个接口而却没有获得他所预期的行为,这个代码不该通过编译;如果代码通过了编译,它的行为就应该是客户所想要的。欲开发一个“容易被正确使用,不容易被误用”的接口,首先必须考虑客户可能做出什么样的错误。
   class Data{
   public:
          Data(int month,int day,int year)
           .... 
   }
    上面这个类如果传入30,3,1990就会出现问题,因为我们没有任何预防机制阻止此类问题的发生
    这个错误可以利用导入新类型而获得预防,我们可以导入简单的包装类型(wrapper types)来处理此类问题。
struct Day{                                                  struct Month{                                                             struct Year{
   explict Day(int d):val(d){}                             explict Month(int m):val(m){}                                     explict Year(int y):val(y){} 
   int val;                                                            int val;                                                                        int val; 
  }                                                                }                                                                               }
  
  从而可以向下面这样调用:
class Data{
        public:
               Data(const Month&m, const &Day, const Year& y);
                ..........
     }
    Data d(Month(3),Day(30),Year(1990));
  对日期进行类似的类型封装,能有效地避免不恰当的日期赋值。
  “除非有好的理由,否则应该尽量令你的类型(定义的类)的行为与内置类型一致”。

  在资源管理方面,也许我们应该“先发制人”,即让函数返回一个资源的指针改为返回一个智能指针。例如:
      std::tr1::shared_ptr<Investment> createInvestment();
      这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内,几乎消除了忘记删除底部Investment对象的可能性。 tr1::shared_ptr提供的某个构造函数接受两个实参:一个是被管理的指针,另一个是引用次数变成0时被调用的“删除器”。 tr1::shared_ptr允许我们自己制定第二个参数,这是安全的。但是留给客户,那也许存在危险。

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

tr1::shared_ptr有一个特别好的性质是:它会自动使用它的“每个指针专属的删除器”,因而消除另一个潜在的客户错误:所谓的“cross-DLL problem”(对象在一个DLL被new创建,却在另一个DLL中delete销毁)。因为它缺省的删除器是来自“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,例如:
     bool validateStudent(const Student& s);     //const,希望别对传入对象进行不恰当的修改;
     这种传递方式效率高得多:没有任何构造函数或析构函数被调用,因为没有任何新对象被创建。
     以传引用方式传递参数也可以避免对象切割问题:即当一个派生类对象以传值的方式传递并被视为一个基类对象,基类对象的拷贝构造函数会被调用,而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了,仅仅留下了基类对象。这一般不是你想要的。
    所以我们一般的做法应该是这样:内置对象和STL的迭代器和函数对象,我们一般以传值的方式传递,而其它的任何东西都以传引用的方式传递。


    请记住:

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

    条款21:必须返回对象时,别妄想返回其reference

  当一个函数“必须返回新对象”时,就让它返回新对象。绝不要返回 pointer 或reference指向一个local stack 对象,或返回reference 指向一个 heap-allocated对象,或返回pointer 或reference指向一个local static 对象。举例说明如下:

(1)如果返回pointer 或reference指向一个local stack 对象(函数的stack对象指函数的参数、局部变量、返回值;存放在函数stack空间):

const Rational& operator* (const Rational& lhs,const Rational& rhs)
{
     Rational result(lhs.n * rhs.n, lhs.d * rhs.d); //警告!糟糕的代码!
     return result;
}

  解释:local对象在函数退出前被销毁了

(2)返回reference 指向一个heap-allocated对象(Heap-based对象指有new 和 malloc之类的函数分配的对象,存放在heap空间)

const Rational& operator* (const Rational& lhs,const Rational& rhs)
{
    Rational* result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
    return *result;
}

  解释:容易导致内存泄露,因为没有谁对new出来的对象实施delete操作。(new 与 delete 成对出现的规则)

(3)返回pointer 或reference指向一个local static:

const Rational& operator* (const Rational& lhs, const Rational& rhs) 
{
    static Rational result;
    result = ... ;
    return result;
}

  在下面的调用中,将出现错误:

if((a * b) == (c * d)){
 //当乘积相等时,做适当的相应动作;
} 
else {
 //当乘积不等时,做适当的相应动作;
}

  解释:(a * b) == (c * d)永远为true,因为两次operator*调用的确调用了各自的 static Rational 对象值,但他们返回的都是Reference,因此调用端看到的永远是static Rational的“现值”。

  所以,我们最终的选择是通过pass-by-value来返回新的对象。

const Rational operator*(const Rational& lhs, const Rational& rhs)
{
    return Rational(lhs.n*rhs.n, lhs.d*rhs.d);
}

 


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

  首先是代码的一致性(调用public成员时不用考虑是成员还是函数)。

  其次封装性,都写成函数进行访问可以提供以后修改访问方法的可能性,而不影响使用方法。另外,public 影响的是所有使用者,而 protected 影响的是所有继承者,都影响巨大,所以都不建议声明成员变量。

     切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允诺条件获得保证,并提供class作者以充分的实现弹性。

  protected并不比public更具封装性。


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

  想像有个class用来表示网页浏览器。这样的class可能提供的众多函数中,有一个用来清除下载元素的高速缓冲区(cache of downloaded elements)、清除访问过的URLs的历史记录、以及移除系统中所有的cookies。

class WebBrowse
{
public:
    void clearCache();
    void clearHistroy();
    void removeCookies();
};

  许多用户想一个函数来执行整个动作,因些WebBrowse也提供这样一个函数:

class WebBrowse
{
public:
    //...
    void clearEverything();//依次调用clearCache(),clearHistory(),removeCookies()
};

  当然这个功能也可以由一个non-member函数来完成:

void clearEverything(WebBrowse& wb)
{
    wb.clearCache();
    wb.clearHistory();
    wb.removeCookies();
}

  问题:那么哪一个比较好呢?

  根据面向对象守则要求,数据以及操作的那些函数应该捆绑在一块,这意味着member函数是较好的选择。不幸的是这个建议不正确。面向对象要求数据应该尽可能被封装。

  member函数带来的封闭性比non-member函数低,因为non-member函数并不增加“能够访问class内之private成份”的函数数量。

  此外,提供non-member函数可以允许对WebBrowse相关机能能有较大的包裹弹性,而那最终导致较低的编译相依度,增加WebBrowse的可延伸性。

  如果我们把WebBrowse相关的功能设计为non-member函数,然后和WebBrowse放在同一个namespace中(namespace可以跨越多个源码文件,而class不能。namespace 可以是不连续的,他有多个文件中定义部分的综合构成,是可积累的

namespace WebBrowsesStuff{
    class WebBrowse{..}
    void clearEverything(WebBrowse& wb)
}

  而这种切割方式并不适用于 class 成员函数,因为一个 class 必须整体定义,不能被切割为片断。

  请记住

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

 


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

 

  当我们为一个有理数类的设计一个乘法操作符的重载函数,如果我们把它作为类的成员:

class Rational
{
public:
    //...
    const Rational operator*(const Rational &lhs);
};

  当我们尝试混合算术的时候,你会发现只有一半行得通:

Rational result, oneHalf;
result = oneHalf * 2;
result = 2 * oneHalf;

  第一个正确,应为它等价于result= oneHalf.operator(2),2发生了隐式类型转换,由于Rational的单参数构造函数是non-explicit的,所以以2为参数调用构造函数生成一个临时对象,然后用这个临时对象和oneHalf做“*”,相当于:

      const Rational temp(2);

      result = oneHalf * temp;

      第二个错误,因为它等价于result=2.operator*(oneHalf)。

  所以,如果我们想执行上面的操作,我们需要将这个重载函数设计为non-member函数。

const Rational operator*(const Rational& lhs, const Rational& rhs);

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

class Rational
{
public:
    Rational(int i):val(i){};
    int getValue() const{return val;};
private:
    int val;
};

const Rational operator*(const Rational& lhs,const Rational& rhs)
{   
    return Rational(lhs.getValue() * rhs.getValue());
}

int main()
{
    Rational lhs(2);
    Rational rhs(3);
    Rational hs=lhs*rhs;
    cout<<hs.getValue()<<endl;
    return 0;
}

 


 

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

 

  • 当std::swap对你的类型效率不高时,提供一个swap成员函数,并确定这个函数不抛出异常。
  • 如果你提供一个member swap,也该提供一个non-member swap来调用前者,对于classes(而非templates),也请特化std::swap。
  • 调用swap时应针对std::swap使用using声明式,然后调用swap并且不带任何“命名空间资格修饰”。
  • 为“用户定义类型”进行std template全特化是好的,但千万不要尝试在std内加入某些对std而言全新的东西。
posted @ 2015-02-05 17:03  wiessharling  阅读(206)  评论(0编辑  收藏  举报