软件工程之面向对象程序设计doc 28页Word下载.docx
《软件工程之面向对象程序设计doc 28页Word下载.docx》由会员分享，可在线阅读，更多相关《软件工程之面向对象程序设计doc 28页Word下载.docx（14页珍藏版）》请在冰豆网上搜索。
主张“以数据为中心”的那一派人关注类的内部数据结构，他们习惯上将private类型的数据写在前面，而将public类型的函数写在后面，如表8.1（a）所示。
主张“以行为为中心”的那一派人关注类应该提供什么样的服务和接口，他们习惯上将public类型的函数写在前面，而将private类型的数据写在后面，如表8.1（b）所示。
ClassA
{
private:
inti,j;
floatx,y;
…
public:
voidFunc1（void）;
voidFunc2（void）;
…
}
classA
表8.1（a）以数据为中心的书写风格表8.1（b）以行为为中心的书写风格
很多C++教课书主张在设计类时“以数据为中心”。
我坚持并且建议读者在设计类时“以行为为中心”，即首先考虑类应该提供什么样的函数。
Microsoft公司的COM规范的核心是接口设计，COM的接口就相当于类的公有函数[Rogerson1999]。
在程序设计方面，咱们不要怀疑Microsoft公司的风格。
设计孤立的类是比较容易的，难的是正确设计基类及其派生类。
因为有些程序员搞不清楚“继承”（Inheritance）、“组合”（Composition）、“多态”（Polymorphism）这些概念。
6.1.2继承与组合
如果A是基类，B是A的派生类，那么B将继承A的数据和函数。
示例程序如下：
classA
voidFunc1（void）;
voidFunc2（void）;
};
classB:
publicA
voidFunc3（void）;
voidFunc4（void）;
//Example
main（）
Bb;
//B的一个对象
b.Func1（）;
//B从A继承了函数Func1
b.Func2（）;
//B从A继承了函数Func2
b.Func3（）;
b.Func4（）;
这个简单的示例程序说明了一个事实：
C++的“继承”特性可以提高程序的可复用性。
正因为“继承”太有用、太容易用，才要防止乱用“继承”。
我们要给“继承”立一些使用规则：
一、如果类A和类B毫不相关，不可以为了使B的功能更多些而让B继承A的功能。
不要觉得“白吃白不吃”，让一个好端端的健壮青年无缘无故地吃人参补身体。
二、如果类B有必要使用A的功能，则要分两种情况考虑：
（1）若在逻辑上B是A的“一种”（akindof），则允许B继承A的功能。
如男人（Man）是人（Human）的一种，男孩（Boy）是男人的一种。
那么类Man可以从类Human派生，类Boy可以从类Man派生。
classHuman
…
classMan:
publicHuman
classBoy:
publicMan
（2）若在逻辑上A是B的“一部分”（apartof），则不允许B继承A的功能，而是要用A和其它东西组合出B。
例如眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是头（Head）的一部分，所以类Head应该由类Eye、Nose、Mouth、Ear组合而成，不是派生而成。
classEye
voidLook（void）;
classNose
voidSmell（void）;
classMouth
voidEat（void）;
classEar
voidListen（void）;
//正确的设计，冗长的程序
classHead
voidLook（void）{m_eye.Look（）;
}
voidSmell（void）{m_nose.Smell（）;
voidEat（void）{m_mouth.Eat（）;
voidListen（void）{m_ear.Listen（）;
Eyem_eye;
Nosem_nose;
Mouthm_mouth;
Earm_ear;
如果允许Head从Eye、Nose、Mouth、Ear派生而成，那么Head将自动具有Look、Smell、Eat、Listen这些功能：
//错误的设计
classHead:
publicEye,publicNose,publicMouth,publicEar
上述程序十分简短并且运行正确，但是这种设计却是错误的。
很多程序员经不起“继承”的诱惑而犯下设计错误。
一只公鸡使劲地追打一只刚下了蛋的母鸡，你知道为什么吗？
因为母鸡下了鸭蛋。
本书3.3节讲过“运行正确”的程序不见得就是高质量的程序，此处就是一个例证。
6.1.3虚函数与多态
除了继承外，C++的另一个优良特性是支持多态，即允许将派生类的对象当作基类的对象使用。
如果A是基类，B和C是A的派生类，多态函数Test的参数是A的指针。
那么Test函数可以引用A、B、C的对象。
voidFunc1（void）;
voidTest（A*a）
a->
Func1（）;
classB:
classC:
//Example
Aa;
Bb;
Cc;
Test（&
a）;
b）;
c）;
以上程序看不出“多态”有什么价值，加上虚函数和抽象基类后，“多态”的威力就显示出来了。
C++用关键字virtual来声明一个函数为虚函数，派生类的虚函数将覆盖（override）基类对应的虚函数的功能。
virtualvoidFunc1（void）{cout<
<
“ThisisA:
:
Func1\n”}
“ThisisB:
“ThisisC:
//输出ThisisA:
Func1
//输出ThisisB:
//输出ThisisC:
如果基类A定义如下：
virtualvoidFunc1（void）=0;
那么函数Func1叫作纯虚函数，含有纯虚函数的类叫作抽象基类。
抽象基类只管定义纯虚函数的形式，具体的功能由派生类实现。
结合“抽象基类”和“多态”有如下突出优点：
（1）应用程序不必为每一个派生类编写功能调用，只需要对抽象基类进行处理即可。
这一招叫“以不变应万变”，可以大大提高程序的可复用性（这是接口设计的复用，而不是代码实现的复用）。
（2）派生类的功能可以被基类指针引用，这叫向后兼容，可以提高程序的可扩充性和可维护性。
以前写的程序可以被将来写的程序调用不足为奇，但是将来写的程序可以被以前写的程序调用那可了不起。
6.2良好的编程风格
内功深厚的武林高手出招往往平淡无奇。
同理，编程高手也不会用奇门怪招写程序。
良好的编程风格是产生高质量程序的前提。
6.2.1命名约定
有不少人编程时用拼音给函数或变量命名，这样做并不能说明你很爱国，却会让用此程序的人迷糊（很多南方人不懂拼音，我就不懂）。
程序中的英文一般不会太复杂，用词要力求准确。
匈牙利命名法是Microsoft公司倡导的[Maguire1993]，虽然很烦琐，但用习惯了也就成了自然。
没有人强迫你采用何种命名法，但有一点应该做到：
自己的程序命名必须一致。
以下是我编程时采用的命名约定：
（1）宏定义用大写字母加下划线表示，如MAX_LENGTH；
（2）函数用大写字母开头的单词组合而成，如SetName,GetName；
（3）指针变量加前缀p，如*pNode；
（4）BOOL变量加前缀b，如bFlag；
（5）int变量加前缀i，如iWidth；
（6）float变量加前缀f，如fWidth；
（7）double变量加前缀d，如dWidth；
（8）字符串变量加前缀str，如strName；
（9）枚举变量加前缀e，如eDrawMode；
（10）类的成员变量加前缀m_，如m_strName,m_iWidth；
对于int,float,double型的变量，如果变量名的含义十分明显，则不加前缀，避免烦琐。
如用于循环的int型变量i,j,k；
float型的三维坐标（x,y,z）等。
6.2.2使用断言
程序一般分为Debug版本和Release版本，Debug版本用于内部调试，Release版本发行给用户使用。
断言assert是仅在Debug版本起作用的宏，它用于检查“不应该”发生的情况。
以下是一个内存复制程序，在运行过程中，如果assert的参数为假，那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了assert）。
//复制不重叠的内存块
voidmemcpy（void*pvTo,void*pvFrom,size_tsize）
void*pbTo=（byte*）pvTo;
void*pbFrom=（byte*）pvFrom;
assert（pvTo!
=NULL&
&
pvFrom!
=NULL）;
while（size-->
0）
*pbTo++=*pbFrom++;
return（pvTo）;
assert不是一个仓促拼凑起来的宏，为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。
所以assert不是函数，而是宏。
程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段。
很少有比跟踪到程序的断言，却不知道该断言的作用更让人沮丧的事了。
你化了很多时间，不是为了排除错误，而只是为了弄清楚这个错误到底是什么。
有的时候，程序员偶尔还会设计出有错误的断言。
所以如果搞不清楚断言检查的是什么，就很难判断错误是出现在程序中，还是出现在断言中。
幸运的是这个问题很好解决，只要加上清晰的注释即可。
这本是显而易见的事情，可是很少有程序员这样做。
这好比一个人在森林里，看到树上钉着一块“危险”的大牌子。
但危险到底是什么？
树要倒？
有废井？
有野兽？
除非告诉人们“危险”是什么，否则这个警告牌难以起到积极有效的作用。
难以理解的断言常常被程序员忽略，甚至被删除。
[Maguire1993]
以下是使用断言的几个原则：
（1）使用断言捕捉不应该发生的非法情况。
不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。
（2）使用断言对函数的参数进行确认。
（3）在编写函数时，要进行反复的考查，并且自问：
“我打算做哪些假定？
”一旦确定了的假定，就要使用断言对假定进行检查。
（4）一般教科书都鼓励程序员们进行防错性的程序设计，但要记住这种编程风格会隐瞒错误。
当进行防错性编程时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警。
6.2.3new、delete与指针
在C++中，操作符new用于申请内存，操作符delete用于释放内存。
在C语言中，函数malloc用于申请内存，函数free用于释放内存。
由于C++兼容C语言，所以new、delete、malloc、free都有可能一起使用。
new能比malloc干更多的事，它可以申请对象的内存，而malloc不能。
C++和C语言中的指针威猛无比，用错了会带来灾难。
对于一个指针p，如果是用new申请的内存，则必须用delete而不能用free来释放。
如果是用malloc申请的内存，则必须用free而不能用delete来释放。
在用delete或用free释放p所指的内存后，应该马上显式地将p置为NULL，以防下次使用p时发生错误。
voidTest（void）
float*p;
p=newfloat[100];
if（p==NULL）return;
…//dosomething
deletep;
p=NULL;
//良好的编程风格
//可以继续使用p
p=newfloat[500];
…//dosomethingelse
我们还要预防“野指针”，“野指针”是指向“垃圾”内存的指针，主要成因有两种：
（1）指针没有初始化。
（2）指针指向已经释放的内存，这种情况最让人防不胜防，示例程序如下：
classA
{
public:
voidFunc（void）{…}
A*p;
{
Aa;
p=&
a;
//注意a的生命期
p->
Func（）;
//p是“野指针”，程序出错
6.2.4使用const
在定义一个常量时，const比#define更加灵活。
用const定义的常量含有数据类型，该常量可以参与逻辑运算。
例如：
constintLENGTH=100;
//LENGTH是int类型
constfloatMAX=100;
//MAX是float类型
#defineLENGTH100//LENGTH无类型
#defineMAX100//MAX无类型
除了能定义常量外，const还有两个“保护”功能：
一、强制保护函数的参数值不发生变化
以下程序中，函数f不会改变输入参数name的值，但是函数g和h都有可能改变name的值。
voidf（Strings）;
//passbyvalue
voidg（String&
s）;
//passbyreferance
voidh（String*s）;
//passbypointer
Stringname=“Dog”;
f（name）;
//name的值不会改变
g（name）;
//name的值可能改变
h（name）;
对于一个函数而言，如果其‘&
’或‘*’类型的参数只作输入用，不作输出用，那么应当在该参数前加上const，以确保函数的代码不会改变该参数的值（如果改变了该参数的值，编译器会出现错误警告）。
因此上述程序中的函数g和h应该定义成：
voidg（constString&
voidh（constString*s）;
二、强制保护类的成员函数不改变任何数据成员的值
以下程序中，类stack的成员函数Count仅用于计数，为了确保Count不改变类中的任何数据成员的值，应将函数Count定义成const类型。
classStack
voidpush（intelem）;
voidpop（void）;
intCount（void）const;
//const类型的函数
private:
intnum;
intdata[100];
intStack:
Count（void）const
++num;
//编译错误，num值发生变化
pop（）;
//编译错误，pop将改变成员变量的值
returnnum;
6.2.5其它建议
（1）不要编写一条过分复杂的语句，紧凑的C++/C代码并不见到能得到高效率的机器代码，却会降低程序的可理解性，程序出错误的几率也会提高。
（2）不要编写集多种功能于一身的函数，在函数的返回值中，不要将正常值和错误标志混在一起。
（3）不要将BOOL值TRUE和FALSE对应于1和0进行编程。
大多数编程语言将FALSE定义为0，任何非0值都是TRUE。
VisualC++将TRUE定义为1，而VisualBasic则将TRUE定义为-1。
BOOLflag;
if（flag）{//dosomething}//正确的用法
if（flag==TRUE）{//dosomething}//危险的用法
if（flag==1）{//dosomething}//危险的用法
if（!
flag）{//dosomething}//正确的用法
if（flag==FALSE）{//dosomething}//不合理的用法
if（flag==0）{//dosomething}//不合理的用法
（4）小心不要将“==”写成“=”，编译器不会自动发现这种错误。
（5）不要将123写成0123，后者是八进制的数值。
（6）将自己经常犯的编程错误记录下来，制成表格贴在计算机旁边。
6.3小结
C++/C程序设计如同少林寺的武功一样博大精深，我练了8年，大概只学到二三成。
所以无论什么时候，都不要觉得自己的编程水平天下第一，看到别人好的技术和风格，要虚心学习。
本章的内容少得可怜，就象口渴时只给你一颗杨梅吃，你一定不过瘾。
我借花献佛，推荐一本好书：
MarshallP.Cline著的《C++FAQs》[Cline1995]。
你看了后一定会赞不绝口。
会编写C++/C程序，不要因此得意洋洋，这只是程序员基本的技能要求而已。
如果把系统分析和系统设计比作“战略决策”，那么编程充其量只是“战术”。
如果指挥官是个大笨蛋，士兵再勇敢也会吃败仗。
所以我们程序员不要只把眼光盯在程序上，要让自己博学多才。
我们应该向北京胡同里的小孩们学习，他们小小年纪就能指点江山，评论世界大事。
升级会员 