Effective C++读书笔记 第四部分 设计与声明

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

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

理想上,如果客户企图使用某个接口而却没有获得他所预期的行为,这个代码不该通过编译;如果代码通过了编译,它的作为就该是客户所想要的。
     欲开发一个“容易被正确使用,不容易被误用”的接口,首先必须考虑客户可能做出什么样的错误。
     许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上,类型系统是你的主要同盟国。

    struct Day
     { 
        explicit Day(int d)        //
explicit 避免隐式的转换。
        :val(d) {}
        int val; 
     }; 

对日期进行类似的类型封装,能有效地避免不恰当的日期赋值。
     “除非有好的理由,否则应该尽量令你的类型(定义的类)的行为与内置类型一致”。

    在资源管理方面,也许我们应该“先发制人”,即让函数返回一个资源的指针改为返回一个只能指针。
     例如:
     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,例如:
    
 bool validateStudent(const Student& s);     //const,希望别对传入对象进行不恰当的修改;
     这种传递方式效率高得多:没有任何构造函数或析构函数被调用,因为没有任何新对象被创建。

    以传引用方式传递参数也可以避免对象切割问题:即当一个派生类对象以传值的方式传递并被视为一个基类对象,基类对象的拷贝构造函数会被调用,而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了,仅仅留下了基类对象。这一般不是你想要的。
    所以我们一般的做法应该是这样:内置对象和STL的迭代器和函数对象,我们一般以传值的方式传递,而其它的任何东西都以传引用的方式传递。
    请记住:

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

当我们领悟条款20中传值的开销后,总是避免于少用传值,然而在返回对象时,要格外小心了,因为你可能:传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。
    任何时候看到一个reference声明式,你都应该立刻问自己,它的另一个名称是什么?
    函数创建新对象的途径有二:在栈空间和堆空间
     栈上:即在函数内的局部变量。局部变量在函数返回后就没有存在的意义,若还对它“念念不忘”,将带来灾难性后果。所以传引用在栈上不可行
     堆上:在堆上构造一个对象,并返回。看似可行,也埋下了资源泄漏的危险。谁该对这对象实施delete呢?别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。

    可能还有一种想法:把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑,以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。
    一个“必须返回新对象”的函数的正确写法是:就让那个函数返回一个新对象。
    编译器实现者实行最优化,用以改善产出码的效率却不改变其观察的行为。所以我们还是老老实实的返回一个对象吧。
    请记住:

  • 绝不要返回pointer或reference指向一个local stack对象,或返回reference指向一个heap-allocated对象,或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。
条款22:将成员变量声明为private

将成员变量隐藏在函数接口的背后,可以为“所有可能的实现”提供弹性。例如,这可使得成员变量被读或写时轻松通知其它对象、可以验证calss的约束条件以及函数的前提和事后状态、可以在多线程环境中执行同步控制......
     不封装意味不可改变!成员变量的封装性与“成员变量的内容改变时所坏量的代码数量”成反比。
     请记住:

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

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

 一般我们相当然以为类中的成员函数更具封装性,而实际上并不是那么一回事,因为成员函数不仅可以访问private成员变量,也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性,因为它只能访问public函数。
    将所有便利函数放在多个头文件内但隶属同一个命名空间,意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多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; // 错误,2,可不被认为是Rational对象;因此无法调用operator*
    可见,这样并不准确,因为乘法(*)应该满足交换律,不是吗?
    所以,支持混合式算术运算的可行之道应该是:让operator*成为一个non-member函数,允许编译器在每一个实参上执行隐式类型转换:
     class Rational 
    {
        ... // contains no operator* 
    }; 
     const Rational operator*(const Rational& lhs,
  Rational& rhs)
    { 
        return Rational(lhs.numerator() * rhs.numerator(), 
                                lhs.denominator() * rhs.denominator()); 
    } 

    Rational oneFourth(1, 4); 
     Rational result; 
     result = oneFourth * 2; 
     result = 2 * oneFourth;  //这下两个都工作的很好,通过隐式转换实现

    成员函数的方面是非成员函数,而不是友元函数。
    可以用类中的public接口实现的函数,最好就是非成员函数,而不是采用友元函数。

    请记住:

  • 如果你需要为某个函数的所有参数(包括被this指针所指的那个隐喻参数)进行类型转换,那么这个函数必须是个non-member。
条款25:考虑写出一个不抛异常的swap函数

请记住:

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值