On The Road
(cond ((less 'code) (less 'bug)))
C++博客
首页
新随笔
联系
聚合
管理
随笔 - 119 文章 - 290 trackbacks - 0
博客搬家了哦,请移步
叫我abc
常用链接
我的随笔
我的评论
我参与的随笔
留言簿
(12)
给我留言
查看公开留言
查看私人留言
随笔分类
《GAME PROGRAMMING GEMS6》读书笔记(4)
《UNIX编程艺术》读书笔记(4)
month-flow(5)
mysql入门(3)
垃圾收集(4)
我的博客
叫我abc
博客搬家啦
搜索
积分与排名
积分 - 300690
排名 - 84
最新评论
1. re: C++ std::fstream open mode
i'am got
--hdj
2. re: cppcheck的使用
你好,你会使用cppcheck吗?@robert
--wqq
3. re: 垃圾收集的那点事(H)
非常感谢
--7Qing_
4. re: 高效调用lua函数
为什么提示没有findLuaItem这个函数?
--sdfasf
5. re: android ndk调试知识[未登录]
博主你好,请问如果没有.so的源代码,应该如何进行arm的汇编级调试呢?
--dennis
阅读排行榜
1. cppcheck的使用(16851)
2. 十步精通新语言(10596)
3. 内存池实现(9852)
4. 高效调用lua函数(9174)
5. 在lua脚本中使用unicode(8127)
读《UNIX编程艺术》第四章
第四章——模块性。
模块有两个很重要的特性,紧凑性和正交性。
紧凑性是指小,拥有较少的public method 数量,能一次看到全貌。虽然书中提倡的10个public method 每个模块,但是难于做到,但是15个以下,还是能做到的。
正交性是“每次只作一件事并做好”的学术词。非正交的method的缺陷是副作用,因为在一次过程中实现了两个事情,或者更具体的说,是函数体内实现了函数名说没有说过要做的事情,并且这件事改变了模块的状态。举个手头上的例子:一个物理对象基类(IPhysxObject)有一个函数计算其子几何体的总质量,名称是_computeTotalMass(dMass &mass)。我在遍历所有几何体算出总质量后,把其设置为物理对象的当前质量——这就非正交了,因为多做了一件事:改变对象的质量。如果把函数名改为_updateMass(void),就没有什么问题。
非正交带来的副作用,虽然说目前熟悉的项目中没问题,但问题是如果你有机会重用这些非正交的模块,你很可能忘却了它带有副作用的地方,或者发现了,却需要额外的代码来抑制副作用。
软件是多层的。在层的设计与实现过程中(自顶向下和自底向上)会出现胶合层。胶合层这个概念很难理解,即使现在仍不能说是理解正确。书上所说是“顶层逻辑和底层原语集阻抗匹配的产物”,软件是通过顶层逻辑加上依赖调用底层原语的函数实现其功能的,那么胶合层是否可以理解为原语调用?那么,所谓的薄胶合,便是从顶层到真正的调用底层原语,其中经历了较少层次的函数调用嵌套。
C被视为薄胶合的语言,我看不出来(缺少根本上的代码量);但是C++作为厚胶合的典范可是很有感触。厚胶合源于类继承层数,即使只是两层,仍会产生很普遍的麻烦,而且这其中还涉及到基类的变量是protected还是private的问题(我以前比较支持private,认为:如果子类需要使用这些变量的话,可以在基类中添加protected的使用原语,退一步还可以添加accessor)。举手头上的例子:
class
Base
{
protected
:
PhysxEntity
*
mpEnt;
public
:
void
Touch(Base
&
obj)
{
//
default impl
mpEnt
->
collide(obj.mpEnt);
}
}
;
class
D1 :
public
Base
{
public
:
void
Touch(Base
&
obj)
{
//
other impl
//
try to access obj.mpEnt
}
}
;
class
D2 :
public
Base
{
}
;
D1 d1;
D2 d2;
d1.Touch(d2);
d1.Touch(d2),需要访问d2的mpEnt(protected),即使是同一基类,到了子类中也是非法的。解决的办法如友元,或者是一个public accessor,或者将D1::Touch实现的功能在Base中做一个原语,但是都不太舒服,不是吗?友元者,对于数量庞大的子类间两两友元,需要多少心力呢?public accessor者,成员变量传统上是不public的,即使accessor,如果返回成员的指针或者引用,那和直接public成员又有多少差别呢?原语者,只是把子类的功能提升到基类实现,然后子类在写Touch函数的时候简单的调用原语。太多原语实现存放在基类,使得基类的尺寸庞大,真的好吗?如果子类要实现的功能不仅涉及基类成员,还涉及子类成员,怎样处理?作为原语引用参数传递,还会直观吗?
有点显然的,accessor,或者基类原语,都不断增加胶合的厚度,因为你总是先要call一个只有一行实现的接口——然后才调用真正的实现,而且真正的实现中,肯定还会有其他执行类似与这种厚胶合···
厚胶合的真正缺陷并不在于函数调用效率,即使调用级数再高也不是主要问题。真正的缺陷是代码的透明性——由于胶合过于雄厚,容易忽略某些零碎的细节,bug之地难以发现,或者code review的时候,完全没有办法看清全貌。
与之相比,C所以平坦,可以说是它没有继承(模仿会使得代码更复杂),同时,访问完全是public的。
posted on 2006-09-10 18:48
LOGOS
阅读(1187)
评论(2)
编辑
收藏
引用
所属分类:
《UNIX编程艺术》读书笔记
FeedBack:
#
re: 读《UNIX编程艺术》第四章 2006-09-10 22:51
万连文
一直想找一本好书静下心看,各种原因总是无法如愿。羡慕你......
回复
更多评论
#
re: 读《UNIX编程艺术》第四章
2006-09-11 09:45
LOGOS
呵呵。你如果时间紧张的话,每天看个3,5页就可以了。
好书是值得慢慢看,并且多看几遍的。
回复
更多评论
刷新评论列表
只有注册用户
登录
后才能发表评论。
【推荐】100%开源!大型工业跨平台软件C++源码提供,建模,组态!
相关文章:
读《UNIX编程艺术》第四章
沉默是金
接口模式:读《UNIX编程艺术》11章感
IPC,读《Unix编程艺术》某章感
网站导航:
博客园
IT新闻
BlogJava
知识库
博问
管理