本文主要是介绍Effective C++读书笔记(条款18-23),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
(四).设计与声明
____________________________________________________________________________________________________________________________________
条款18:让接口容易被使用,而不容易被误用
#1.导入新类型可以让接口不易被误用,以函数替换对象则可以保证类型安全性。例如:
class Date{public:Date(int month, int day, int year);...
}
//加上外覆类型:
class Month{
public:static Month Jan(){return Month(1);}static Month Feb(){return Month(2);}...static Month Dec(){return Month(12);}...
private:explicit Month(int m);...
};
struct Day{
explicit Day(int d): val(d) {}
int val;
};
struct Year{
explicit Year(int y):val(y){}
int val;
};
//则可以这样调用:
Date d(Month::Mar(), Day(30), Year(1995));
//从而保证了类型安全性和接口不易被误用。
#2.限制类型内什么事可做,什么事不可做可以预防客户错误。
例如,用const修饰operator*的“返回类型”可阻止客户因”用户自定义类型“而犯错。
if(a*b = c)... //喔噢,原意其实是要做一次比较动作
#3."保证接口的一致性","让types行为与内置types的行为一致”可以促进接口被正确使用。
#4.任何接口要求客户必须记得做某些事情,就是有着”不正确使用“的倾向。
例如,有函数:
Investment* createInvestment();
并希望最后将Investment*指针传递给名为 getRidOfInvestment()函数,则给了
客户三次犯错误的机会:没有删除指针,删除指针多次,没有用getRidOfInvestment()函数来删除指针
我们可以将其改成如下代码:
std::tr1::shared_ptr<Investment> createInvestment()
{std::tr1::shared_ptr<Investment> retVal(static_cast<Investment*>(0),getRidOfInvestment);retVal = ...; //另retVal指向正确对象return retVal;
}
这样便可以防止客户犯错,避免造成资源泄漏。
#5.tr1::shared_ptr支持定制型删除器(custom deleter),这可用来防范DLL问题,可被用来
自动解除互斥锁(mutexes;见条款14)等。
____________________________________________________________________________________________________________________________________
条款19:设计class犹如设计type
#1.新type的对象应该如何被创建和消耗?
#2.对象的初始化和对象的赋值该有什么样的差别?
#3.新type如果被passed by value(以值传递),意味着什么?
#4.什么是新type的"合法值"?
#5.你的新type需要配合某个继承图系(inheritance graph)吗?
#6.你的新type需要什么样的转换?
#7.什么样的操作符和函数对此新type而言是合理的?
#8.什么样的标准函数应该被驳回?
#9.谁该取用新的type的成员?
#10.什么是type的"未声明的接口"(undeclared interface)?
#11.你的新type有多么一般化?
____________________________________________________________________________________________________________________________________
条款20:宁以pass-by-reference-to-const 替换 pass-by-value
#1.对于自定义类型,尽量以pass-by-reference-to-const 替换 pass-by-value,前
者通常比较高效,而且可以避免切割问题。
(避免构造函数和析构函数所带来的成本)
#2.对于内置类型,STL的迭代器及函数对象,pass-by-value比较适当。
(这部分符合C守则,没有构造函数带来的成本, pass-by-value通常比指针来实现
的reference更高效)
#3.对于小型自定义类型,仍应使用passed-by-reference-to-const。
理由1:
对于小型拥有并不昂贵的copy构造函数,某些编译器对待”内置类型“和”用户自定义类型“
的态度截然不同,纵使两者拥有相同的底层表述。
例如:
某些编译器拒绝把只由一个double组成的对象放进缓存器内,却很乐意在一个正规基础上对
光秃秃的double这么做。
因此使用passed-by-reference-to-const传递比passed-by-value更好。
理由2:作为一个用户自定义类型,其大小容易有所变化。
理由3:改用不同的C++编译器可能改变type的大小,比如:某些标准程序库实现版本中的
string类型比其他版本大七倍。
____________________________________________________________________________________________________________________________________
条款21:必须返回对象时,别妄想返回其reference
#1.用pointer或reference指向一个local stack对象,并在函数中返回,都将导致
”无定义境地“的不明确行为,因为locak stack对象在函数返回时就被销毁了。
#2.返回pointer或reference指向一个local static而有可能需要多个这样的对象
会使多个对象同时指向一个对象,这很可能并不是一开始你所希望的。
例如:
const Rational& operator*(const Rational& lhs, const Rational& rhs)
{static Rational result;result = ...;return result;
}
bool operator==(const Rational& lhs, const Rational& rhs);
Rational a, b, c, d;
...
if((a*b)==(b*d)){//当乘积相等时,做适当的相应动作;
}else{//当乘积不相等时,做适当的相应动作;
}
结果总是执行相等时的语句块,因为返回的总是同一个local static对象,
这并不是当初我们所希望的。
____________________________________________________________________________________________________________________________________
条款22:将成员变量声明为private
#1.切记将成员变量声明为private,这可赋予客户
(1).访问数据的一致性(都通过函数访问),
(2).可细微划分的访问权限(不准访问,只读访问,只写访问,读写访问),
(3).允许约束条件获得保证(通过函数验证class的约束条件,通知其他对象,
验证函数的前提和事后状态,在多线程状态中执行同步控制...等等。)
(4).增加class的封装性,及实现弹性(访问控制增加封装性;客户统一调用,
却可改变的函数内部行为增加了实现弹性)
(5).确保class的约束条件总是会获得维护,因为只有成员函数可以影响它们。
#2.某些东西的封装性与“当其内容改变时可能造成的代码破坏量”成反比。
(所谓改变,也许是从class中移除它(这或许有利于计算封装性))
#3.protected并不比public更具封装性。
理由:public成员变量供所有使用它的客户所使用,如果移除了它,所有使用
它的客户码都会被破坏,因此封装性为0, protected成员变量被所有derived
classes和class本身所使用,如果移除了它,所有使用它的客户码也都遭到
破坏,因此封装性也为0.
____________________________________________________________________________________________________________________________________
条款23:宁以 non-member, non-friend 替换 member 函数
#1.如果某些东西被封装,就会降低其可见性,愈多东西被封装,愈少人可以看见它。
而愈少人可以看见它,我们就有愈大的弹性去变化它,因为我们的改变仅仅影响那些
看到改变的人或事物。
#2.宁可拿 non-member, non-friend函数替换 member 函数。这样做可以增加
(1)封装性:
non-member、non-friend函数比member函数更缺少访问class中内部protected成员
和private成员的权限,换言之,能看到的更少,因此,封装性更好。
(注意,这里为什么不包括friend函数)
(2)包裹弹性:
non-member、non-friend函数的封装将class与该函数分离,减少了代码修改的
编译依存性,因此具有更高的包裹弹性。(说白了,就是与class更无关了)
(3)机能扩充性:
non-member、non-friend函数可以被置于与class相同的namespace内,如此一来
便可实现多组分别位于不同源文件的便利函数,从而实现了分离的扩充机能。
(namespace可以跨越多个源文件,而class不行)
例如:
//-----------------------------------
#include"WebBrowser.h"
namespace WebBrowserStuff{
class WebBrowser{...};
... //核心机能,例如几乎所有客户所需要的 non-member函数
}
//-----------------------------------
#include"WebBrowserBookmarks.h"
namespace WebBrowserStuff{
... //与书签相关的便利函数
}
//-----------------------------------
#include"WebBrowserCookies.h"
namespace WebBrowserStuff{
... //与cookies相关的便利函数
}
//-----------------------------------
//此时若想再添加一组便利函数,只需要包含相关的头文件,便可以在 namespace
//中轻松的再添加,实现扩展机能。<pre name="code" class="cpp">//=============================================================
// 以下是一个使用member函数和non-member、non-friend函数的示例:
//=============================================================
class WebBrowser{
public:...void clearCache(); //清除下载元素缓存void clearHistory(); //清除访问过的URLs历史记录void removeCookies(); //移除系统中所有的Cookies
};
//若想将上述三个函数一同实现,可采用member()函数,和non-member、non-friend函数的方式,
//其中member()函数实现方式:
class WebBrowser{
public:...clearEverything(); //调用clearCache,clearHistory,removeCookies函数...
};
//non-member、non-friend函数实现方式:
void clearEverything(WebBrowser& wb)
{wb.clearCache();wb.clearHistory();wb.removeCookies();
}
____________________________________________________________________________________________________________________________________
这篇关于Effective C++读书笔记(条款18-23)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!