csdn任命小版主是否应该先通知大版版主？——请csdn的相关管理者尽快给与回答！

青润 2003-09-12 10:21:28
我有两个问题需要解决，都是最近发生在软件工程板块的问题，因为最近软件工程板块已经开始乱了，所以，我不得不提出这个问题：
第一、csdn任命小版主是否应该先通知大版版主，任命同级的大版主可以不通知，但是单独任命一些小版主，是否应该通知？
因为软件工程板块最近任命的几个小版主在相关领域没有什么特殊的建树，而且，问题也并不多，解答也不是很积极，这些人的资格和影响力让人怀疑！
第二、如果不是csdn任命的，那么某一个大版主任命小版主，是否应该让另外一个大版主也知道任命的原因？
请csdn的管理者尽快给与回答！
...全文
108 97 打赏 收藏 举报
写回复
97 条回复
切换为时间正序
当前发帖距今超过3年，不再开放新的回复
发表回复
LiwuxLiang 2003-09-19
ozzzzzz(希望敏捷)
你的话让我想到经常会有某某大楼说‘衣冠不整...穿拖鞋者...不的入内’，事实上穿吊带装、拖鞋式凉鞋的人多了，他们进去的时候门卫还是笑脸相迎，因为来的都是客。（没有比喻你的意思）
就象作软件，要考虑市场，而不仅仅是技术。固然技术是跟本，可是不迎合市场肯定活不了几天。我知道你要说专业市场，那也是买方说话。在CSDN上面，是有许多人胡乱灌水，你怎么就知道他们没有认真地在里面学习呢？只是每个人的表现方式罢了。你把这些人统统赶出去，或者不许他们发表你不喜欢的言论，就靠你所谓的遵守秩序的人就真的提高中国IT的专业水平了么，就能提高行业荣誉感了么？

再有，你希望用什么标准来衡量你所谓的专家呢？专家不也要点点累计么？
是有很多家伙看过几本说 听到过一些名词就来和‘你们’说东说西的，不过是可以只了解思想不去深入啊，世界上值得研究的东西多了，何必都去苦苦深究，只要略知一二，需要的时候想的起来即可，更何况触类旁通呢。通过讨论或许豁然开朗，何必要花那么多时间。

你说‘我才不会在乎是不是有多少人听我说 我只在乎有多少能听懂我言论的人在听我说'
可是你就以为你的言论方式最能启发受众么？也许慕名而来的新手会发现自己必须先登一万个台阶才能到得了你的门口，推门一看也不过是在胡说八道罢了。我看你只是在找目标听众，听得懂你的听众，满足你的演讲欲，而不是以宽厚之心启发后辈。

我在这里和你争论，其实一部分出于对青润离开的关注，也就是你说的讨论事情，另外一部分是出于好玩。

还是引用竹马的话：

小辈意见
谬误百出
不敬之处
万望见谅


  • 打赏
  • 举报
 回复 赞
zhuma 2003-09-19
竹杖芒鞋轻胜马
一蓑烟雨任平生
  • 打赏
  • 举报
 回复 赞
Panr 2003-09-19
----------
w102272(Wonder) ( ) 信誉：100 2003-9-17 15:14:51
说说我的看法，我一向强调责权利统一。
我们每个来这里的人都是用自己的时间精力，问题来交流，得到知识，结交朋友，甚至得到项目，工作机会，产品构想，方案等等更有价值的东西。
CSDN利用我们的付出，得到人气（论坛），得到高手的文档（文档中心），得到作杂志和发展相关业务的素材，发展其企业品牌。


答：
其实原来我很不服气这句话，因为ＣＳＤＮ出版《程序员》的时候也是声称这是程序员自己的杂志，我一直都把ＣＳＤＮ当作软件业内杂志，以振兴软件业为己任

最不能接受的是ＣＳＤＮ竟然没有发布官方意见，也许默许就是它的表态
也许我一直都是错的，侯捷肯定是作家而不再是程序员，那么ＣＳＤＮ也只是出版商，它只关心它的出版物而不是软件行业

不管怎么说，还是感谢ＣＳＤＮ免费提供这个论坛，它使我在这里认识了一些同行
希望ＣＳＤＮ能组织到更多更好的文章，促进中国软件技术的交流，赶超O'Reilly



----------
to qingrun:
其实也没什么，地球又不会停转，ＣＳＤＮ生意照做，也相信您的软工兴趣依旧
只是一个选择而已，尸位素餐何足留恋，走了就走吧
  • 打赏
  • 举报
 回复 赞
johnsonqian 2003-09-19
呵呵，青润在那里还是版主啊
  • 打赏
  • 举报
 回复 赞
suowei15 2003-09-19
呵呵。。完了？

这种贴该放下来了，这种斑竹88了也罢！

切~~地球又不会停转！
  • 打赏
  • 举报
 回复 赞
johnsonqian 2003-09-19
To：青润、巴山雾及各位在北京的本版同行们：

记得大家曾经在青年宫做过一次聚会，那次本来我也报名了，结果当天有事情，就没去成，也就无缘见面。当时想反正在网上一样也能沟通，可是，今天居然连青润都走了。
上面有我的两个回复，本希望能劝的青润版主留下，可终于没有成功。
最近自己工作中也很有些不痛快，深刻感受到在公司的良苦建议不被人采纳的痛苦，但却不得不为了生活继续待下去。
自己虽然算不上高手，但有时候在网上也对一些帖子做些回复，希望对新人们有些帮助。但总体感觉是很无奈：这个领域目前整体还是不被业界所理解、尊重，本希望通过大家的努力将饼做大些，让规范的软件企业更多些，可这条路实在漫长，有空也想当面和北京的同行们聊聊这些话题。
总之，我本来就不像青润版主那样天天关注本版，过去不曾，将来也不会，但还是会偶尔上来看看。
青润走了，不知道这版还会不会恢复生机，但愿吧。
  • 打赏
  • 举报
 回复 赞
Rose2000 2003-09-19
差点忘了他告别中最重要的一句：

“各位如果要找我，可以到www.smiling.com.cn上的iTSP小组来找我。”
  • 打赏
  • 举报
 回复 赞
Rose2000 2003-09-19
在此，我转发青润的给大家的“真情告别”：

“再见了，各位朋友。
我已经取消了我在软件工程板块上斑竹的位置，今后，我将几乎不再到这里来了。
我也封杀了qingrun这个账号，虽然，到现在还没有显示出封杀的状态，但是，我也已经再也不能在软件工程板块发贴子了，系统提示：该用户信誉分不够。”
  • 打赏
  • 举报
 回复 赞
CppFile 2003-09-19
一场闹剧结束了
  • 打赏
  • 举报
 回复 赞
ozzzzzz 2003-09-18
zhuma(竹马)
嘿嘿 你还很会自己给自己找帽子带
其实我不是说新手的参与降低了水平 而是说新手的乱参与降低了水平 比如你来问我问题 可是我却找不到你的问题和发言 它们被淹没在一个海洋中了 而那些找文档模板的人 如果你给出的www.51cmm.com可以解决 为什么他自己不去找 而要来这里问 难道不会用google和baidu吗 一些问题在faq和精华区都有 为什么不去查一下 这个我想清润也很不喜欢 其实关键的是一个帖子要有深度 要能讨论出一些问题了 如果只是抱着一直抢分 而不是研究问题的态度 对你和对别人都是没有好处的 越激烈越好 你也看到了 我喜欢和人辩论 越辩论我越痛快 往往都会把回复的30次用完 如果能有这样的话题 我高兴还来不及 但是你看到最近有这样的话题吗 为什么会没有了 至少原来有很多的人和我辩论 是不是我真的很霸道 把别人都骂跑了 我想我不会是这样的的面孔吧 嘿嘿 不过如果真的是 那就请多包涵 也请提出来 我其实是一个闻过则喜的人
其实我说还不如放开大家散分 这样你自己想要多少就可以要多少 干脆就来一个放分区 这样更好 只要你想要星星 你就去那里拿 关键是你要明白 一个好的社区应该是对大家都有好处 如果只是让那些初学者感到高兴 那未必是好事情
而说到对后辈的提携问题 我想只能对那些希望被提携的人提携 而不看你对那些不希望提携的人提携 而且社区的混乱也不利于这样的提携 至少向清润这样的人走了 很多人就再也很难找到他 更多的人不像你我和他见过面 有联系方式
其实我一向讨厌分这个东西 就像我讨厌中国的高考一样 这个东西对你没有什么实际的意义 他也不能换钱 也为你找不到更好的工作 当然你也可以说我玩物丧志（这个词的实际意义是 追求现实的东西 而忽略了心灵的需要 嘿嘿 其实那些说玩电子游戏玩物丧志的人 往往都是那些望文生义的家伙 他那样说其实自己就玩物丧志） 我也没有办法 毕竟有那个星星可能对你是一件很高兴的事情 但是我想你应该会有更多的追求 毕竟失去那些真正有水平的人对你也是一个损失 而这个社区的生命是建立在有没有一批高水平的参与者 而不是看有多少水手
  • 打赏
  • 举报
 回复 赞
Panr 2003-09-18
－－－－－－－－－－
如果ＣＳＤＮ管理员有在看这个贴的话
我建议为每个帖子设计一个“最低回复信誉分”的属性
“最低回复信誉分”的默认值可以设置为９５，并可被楼主和斑竹修改
当回复人在该版块的信誉分低于“最低回复信誉分”时，回复就会报错，被拒绝

因为回复检查本来就有，要加这个东西的话应该不复杂
而回复人信誉分是和版块有关的，这样做应该不会给一般使用者带来不便


－－－－－－－－－－
如果ＣＳＤＮ管理员还没看这个贴的话
我支持qingrun 前辈辞职，做斑竹就要担待一些责任，这包括引导论坛倾向于技术还是娱乐
既然前辈已经不可能保持这种影响力了，尸位素餐有何留恋

至于封杀帐号一说，到也不必
至少你也是此道中人
至少这里现在还是在中国有一定影响力的软件工业重镇



－－－－－－－－－－
to ozzzzzz(希望敏捷):
支持你的论坛倾向，因为技术重于娱乐
“大凡君子与君子，以同道为朋”，技术之道才是关键

而开放性也是论坛的一个好处，如果规模太小的话，很难谈什么“结交新朋友”
毕竟这里已经发展了这么长时间了，有一些名气，新人有时也会逛到这里来的
  • 打赏
  • 举报
 回复 赞
johnsonqian 2003-09-18
zhuma(竹马)
你的建议挺好的。

不过提醒一句先：ozzzzzz(希望敏捷)前辈估计不喜欢你这样去和他建议的“学生之类的人”，如果他有时间，他会和你争辩到底的。呵呵，我就曾经在一个帖子里见到了他和人雄辩的风采，他的对手一拨又一拨，但后来他的对手都退出了。
不过，你如果关注他的帖子，可以发现他的确水平很高，经验也丰富。从这个角度看，多听听他的也挺好的。

ozzzzzz(希望敏捷)前辈
呵呵，如有得罪，请勿介意，后生先赔礼了。
  • 打赏
  • 举报
 回复 赞
zhuma 2003-09-18
To ozzzzzz(希望敏捷):

ozzzzzz(希望敏捷)前辈
我想我应该是你所说的
“水平越来越差 到处是一些学生之类的人”
“真正有时间在这里泡分的人往往都是工作不忙的人 而这样的人你说会是什么样子”
还有其它的一些类似发言的针对对象之一

首先承认本人近期的确处于掠分的状态中
水分确实很重
主要是想混个星星好玩：）
可作为一个软工的新手
我的确希望通过csdn软工版向诸位前辈学习

您认为新手的参与
降低了板块的水平和含金量
这一点我是认同的

但您对此采取非我族类其心必异的态度
我表示不理解
个人认为高水平论坛的职能之一应该是
传播思想提携后进
因此对新鲜血液采取排斥行为我认为是不合适的

之于高级讨论区
我认为可以采用资格认证的准入方式
先建立一个高级讨论区及其会员资格认证委员会
认证委员会对每一个希望加入高级讨论区的csdn会员进行资格审查
只评议其所发贴子的质量而不看专家分
如认可，其即成为高级讨论区的会员，可以参与高级讨论区的辩论
而一般csdn会员有对高级讨论区旁听的权利

小辈意见
谬误百出
不敬之处
万望见谅
  • 打赏
  • 举报
 回复 赞
johnsonqian 2003-09-18
很赞成 w102272(Wonder)的处理意见。
我想大家来CSDN这个论坛的目的逃不过这么几个：
1、学习新东西
高手们不是很喜欢的初学者都是报着这种心态来CSDN的，而高手遇到自己不擅长的知识点也愿意上来看看，毕竟高手不可能“十八般武艺、样样精通”，所以，CSDN从这个意义上说，是非常好的。不过，对于高手来说，他往往只能回答问题，自己的问题却没有好的答案，对这点就兴趣不大。
2、结交新朋友
如果一个人发现有另外一群人平时做的事情和自己很相似，他自然想加入这个群体，交流体会，共通有无。这点，就是楼主、o6z等等成为朋友的缘故。而这时，CSDN只不过成为他们结识朋友的一个渠道了。
3、体会受人尊重的感觉
这个“体会受人尊重的感觉”，如果别人发现你的网名后面是星而不是三角，如果你回答了问题后别人由衷的感谢你甚至赞叹你，这种“体会受人尊重的感觉”会让人很快乐。不用回避，这是人之常情，谁都会这样的。
4、闲的无聊
工作不紧张，老板很少关注自己，于是乎四处灌水。这种人不少，有时候感觉挺讨厌，楼主希望管理的也就是这帮人。但是，高人有时候也会闲下来，也会灌点水，对灌水者一帮子打死似乎也不容易，从制度上也很难去自动过滤，所以，版主就不得不反复删除这些灌水帖。
5、打广告
这个其实也是灌水帖的一种，如果有办法直接删除就最好了。但是，路上遇到发宣传单的年轻人，有时候为了关照他一下，还是象征性的接过来看几眼，走几步再扔到垃圾桶。再网上面对这些广告，有时候也有类似心态吧？
6、发泄情感
女朋友过生日了，会发个帖子散分，甚至让大家给他女朋友发短信祝福再散分（我一直不明白大家要分有什么好处，它值钱么？）；老板开了他或者他的好朋友，也会上来大骂一通；公司的什么不合理，当面不敢说，就在网上发泄不满；如此这般，也有些帖子，有的人为了分、有的人为了凑热闹、有的人有同感，于是，这种帖子还是有些市场的。

仔细想想，上面的种种情况都是可以理解的，而楼主的心情更可以理解了：他是个有原则的人，毕竟他不得不做大量的整理工作，还得回答很多网友的问题，如果楼主不用上班，或者还可以；而如果他上班很忙，甚至如果工作也不爽，想让楼主有好心情去处理他认为的垃圾帖子，实在是有点难为人。更何况，他的原则CSDN的管理员基本不理睬。

但我想，楼主一定还是对这个论坛期望很高的，希望论坛能按照自己的期望办好（当然，CSDN管理者似乎并不领情），所以，假设CSDN管理者真得按照楼主的意思照办了，楼主还是会尽心尽力的，不是么？
那么，如果实在不能改变，是否非退出论坛不可呢？我想起《倚天屠龙记》里的黄衫女子，论高手，她在那本书里应该是数一数二吧，但她却选择在关键的时刻出现。如果她去华山比试，估计是天下第一的有力竞争者，但她不去。可是，不去并不意味着她不关注，在该出现的时候，她都出现了：拯救丐帮、帮助张无忌等等。从这点，我想楼主不妨学学黄衫女子的超脱，辞职倒太夸张了，就是淡出好了，每天还是可以上来看看，看到水手的帖子，大不来不看，遇到有意思的帖子，参与一下岂不是很好。何况，楼主也得工作，也得生活，即使还做楼主，天天工作之余又做这么多论坛管理，本身也很辛苦的。
这里，我倒有三个建议：
1、对于帖子，可以在技术上做关键词整理，大家进入小论坛界面后，可以在鼠标移过该帖子时显示该帖子的关键词或者前两行，透过这个，可以看到是否水手帖，如果是，不看即可；如果是精品，自然还是可以仔细看的；
2、FAQ区域应该有选择，新手常问的问题可以归纳到那里，并在论坛显著地方标识，免得新手老问同样的问题，高手就不乐意看。而这些新手常问的问题，有些或许很有讨论价值，高手们的答复都在FAQ区域，也可以不断更新啊；
3、可以对帖子进行几种排序选择。目前是按照最新更新的顺序排的，这就必然造成反复进行“顶”帖子的现象出现，我建议可以按照回复次数、更新顺序、高手参与等级分（该帖子高手参加的多，该分数就高，是精品的几率就大）等多种方法进行排序，这样，大家可以有选择的余地。现在，大家忙起来就只看前面的一两篇，而水手帖却都在前面，精品却在后面没有人注意，这个本身就不合理。

总而言之，再次建议楼主不必一走了事，请三思。
  • 打赏
  • 举报
 回复 赞
chump 2003-09-18
不管风风雨雨，大家共同进步！我是这里的新人。
  • 打赏
  • 举报
 回复 赞
hbhdlzq 2003-09-18
今天是九一八，俺放点水

产品类别 坚决抵制日本鬼子的产品品牌或者品牌 推荐替代品牌

数码相机和摄像机 富士、柯尼卡、索尼、JVC、松下、 中国联想韩国三星，
东芝、奥林巴斯。（这些公司均出资支持 美国柯达
日本右翼修改教科书，否认南京大屠杀和
侵华史实。）


汽车 本田、丰田、铃木、日产、三菱。 低档品牌：福莱尔、吉利
（这些公司是日本重工业的支柱，也是日本主要 中档品牌：红旗、大众、
武器装备制造商,他们壮大就是日本军事工业的 现代、别克赛欧、
壮大 菲亚特、斯科达等
品牌大致如下：丰田_TOYOTA、威驰_Vios、 高档品牌：中华、奔驰、
本田_HONDA、尼桑_Nissan、途乐_Patrol、 宝马、奥迪等
日产_Nissan、佳奔_Urvan、三菱_MITSUBISHI、
阳光_Sunny、十五铃_ISUZU、宏达_HONDA、
铃木_SUZUKI、凌治_Harrier、碧莲_Civilian、
风度_Cefiro、 蓝鸟_Nissan、 马自达_Mazda
奇骏_X-trail、


电器 JVC、 松下、东芝、卡西欧等 长虹、TCL、春兰、厦新等

日本料理 吉野家（连锁快餐）、味千拉面等。 如果您爱吃生鱼，韩国的也不错。
日本人的食品中看不中吃，不说也罢。

计算机类 日本计算机类产品在品牌上不占优势。 联想、方正、IBM、DELL等
以上的推荐产品里也许有日本生产的零部件，
但是请记住，抵制一分是一分。

软件类 假如你想使用日本人的软件，满街的盗版，
你又何必给日本人送钱？——这并不代表
我们支持盗版 日货最好的替代品是中国人
的尊严和对后代的责任感

手机类 松下、索爱、NEC、京瓷 夏新、波导、TCL、康佳、联想

家用电器 索尼SONY、佳能CANON、JVCTDK 替代产品很多很多！
及办工器材 松下_Panasonic、卡西欧_CASIO、
建伍_KENWOOD、爱华_aiwa、
精工_SIEKO、尼康_NIKON、日立_HITACHI、
兄弟_Brother、先锋_Pioneer、
东芝_TOSHIBA、八重洲_YAESU、
阿尔派_ALPINENEC、百乐NTT、
美能达_Minolta、斑马_ZEBRAKDDI、
奥林巴斯_Olympus、蜻蜓_DragonflyDoCoMo、
夏普_SHARP、富士通_FUJITSUTUKA、
爱普生_EPSON、美上美_MITSUMIJ-PHONE、
理光_Ricoh、京瓷_Kyocera、柯尼卡_KONIKA、
三洋_Sanyo

化妆品 资生堂_SHISEIDO、DHCMILD、花王_KAO、 替代产品很多很多
及日常洗化等 狮王_LION、诗芬_sifone、碧柔_Biore、
多芬_Dove、乐而雅_Laurier、高丝_KOSE、
naturgo

烟酒及食品等 柔和七星、明治食品、四洲食品、 本土品牌有很多很多！
麒麟啤酒、午后红茶LUCIDO、朝日啤酒、
BOSS咖啡、日清食品、日本酒、雪印食品、
Suntory茶、味千拉面

服装等 美津浓_MIZUNO、爱斯克斯、日高_NIKKO、 中国是世界第一服装大国！
华高青山洋服（服饰）

百货 伊藤洋华堂_Ito、Yokado_成都、 中国是百货业强国之一！
华堂_Ito、Yokado_北京

其他 立邦油漆、TOTO卫浴、富士胶卷、
FUJIFILM、松本电工、爱眼眼镜、
精工眼镜、横滨轮胎、第一生命（制药）
武田药品、太田胃药、森永化工、OKI（针打）
野尻（眼镜）、 伊都锦、 优衣库、
八仟代、AKAI、 内野（家纺）
  • 打赏
  • 举报
 回复 赞
arfayr 2003-09-18
o6z说得很有道理

这样的一个环境不是那么好创建的，不如建一个相对封闭的论坛，进入的成员需要经过考核。授权才能发言，别人只能看，不能说

不过，CSDN的论坛目的只是吸引人吧，似乎还没人认真考虑分析如何更加让这个论坛合理对大家有益
  • 打赏
  • 举报
 回复 赞
ozzzzzz 2003-09-18
其实根本原因还是方向问题
其实csdn也是没有办法 我当初问过他们 为什么不把杂志办的专业性强一些 他们说其实他们也是想把 程序员 办成一个高水平的专业杂志 想主要服务于cio 总工 工程师 可是那样销量就会上不去 而现在的广告商只任销量 所以他们为了生存也是没有办法 这就就是现在的社会现实
而作为我们来说 给我们这些有专业要求的人作交流 希望的是给我们的工作有帮助 而这样势必会把广大的学生用户排除在外 而那些工作新手也会感到不习惯
例如一个人问如何作项目管理 于是马上就会有人出来给他一个网址 大概多数是www.51cmm.com这样的垃圾网站 而作为我们却不知道怎么回答这样的问题 因为这样的问题太宽泛 太复杂 无从下手 如果是用来聊天可以 但是用来讨论就很不合适 不如问这样的问题 我想作一个项目管理过程中checklist（只包括20个问题） 这样的问题虽然也很复杂和宽泛 但是可以找到下手的地方 同时在实际的工作上也用的到
而灌水也是很让人觉得不好办的 如果是为了把帖子提前 或者作一个参与的记号以便容易查询 那也好说 但是很多时候只是单纯的灌水 而且有些人的签名还很创意 搞得大家看论坛得时候很麻烦（至少我有时是用电话拨号的 网页打开得速度很慢） 也不利于看清楚问题
还有就是专家分问题 其实那个分数就和垃圾差不多 至少我知道wonder和爱忘记就还分数很低 如果真搞一个只能到达一定分数才可以参加得分区 对我们也不是很好 至少有些人就会参加不进来 当然你要说分数体现了对社区得贡献 其实我看未必 比如wonder的发言就很有内涵 但是他是不到时候不发言 一般的问题就被他略过了 而他对问题的看法 要比那些所谓的高手有意义的多 其实说白了 真正有时间在这里泡分的人往往都是工作不忙的人 而这样的人你说会是什么样子 好在我最近刚要转型 所以才无聊来看看 不然我也是没有什么兴趣来这里 真的已经很烂了 至少比去年这个时候要差多了 我也不知道为什么会这样 毕竟半年没有来 不知道究竟发生了什么 似乎zzroom也好久不见
  • 打赏
  • 举报
 回复 赞
青润 2003-09-18
to wolfsquare：
谢谢老兄。我知道老才做的方向。只是怀念这些兄长，感慨过去接受他们教诲的时光呀。现在，让我在这里帮助别人，我真的觉得……

我打算现在给蒋涛和曾登高发邮件了。让他们过来看看这个贴子。
  • 打赏
  • 举报
 回复 赞
wolfsquare 2003-09-18
另外说句题外话,我想老才不来的重要原因之一是目前软工对他的公司用处不大. :)
  • 打赏
  • 举报
 回复 赞
加载更多回复
相关推荐
二十三种设计模式【PDF版】
主要是介绍各种格式流行的软件设计模式，对于程序员的进一步提升起推进作用，有时间可以随便翻翻~~ 23种设计模式汇集 如果你还不了解设计模式是什么的话？ 那就先看设计模式引言 ! 学习 GoF 设计模式的重要性 建筑和软件中模式之异同 A. 创建模式 设计模式之 Singleton(单态/单件) 阎宏博士讲解：单例（Singleton）模式 保证一个类只有一个实例,并提供一个访问它的全局访问点 设计模式之 Factory(工厂方法和抽象工厂) 使用工厂模式就象使用 new 一样频繁. 设计模式之 Builder 汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder 模式就是将这两 种情况分开进行。 设计模式之 Prototype(原型) 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 B. 结构模式 设计模式之 Adapter(适配器) 使用类再生的两个方式:组合(new)和继承(extends),这个已经在 thinking in java中提到过. 设计模式之 Proxy(代理) 以 Jive 为例,剖析代理模式在用户级别授权机制上的应用 设计模式之 Facade(门面？) 可扩展的使用 JDBC针对不同的数据库编程,Facade提供了一种灵活的实现. 设计模式之 Composite(组合) 就是将类用树形结构组合成一个单位.你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于 和单位做买卖。文章中还对 Jive再进行了剖析。 设计模式之 Decorator(装饰器) Decorator 是个油漆工,给你的东东的外表刷上美丽的颜色. 设计模式之 Bridge(桥连) 将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合) 设计模式之 Flyweight(共享元) 提供 Java运行性能,降低小而大量重复的类的开销. C. 行为模式 设计模式之 Command(命令) 什么是将行为封装,Command 是最好的说明. 设计模式之 Observer(观察者) 介绍如何使用 Java API 提供的现成 Observer 设计模式之 Iterator(迭代器) 这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中， 直接使用 Iterator 进行对象遍历。 设计模式之 Template(模板方法) 实际上向你介绍了为什么要使用 Java 抽象类,该模式原理简单,使用很普遍. 设计模式之 Strategy(策略) 不同算法各自封装,用户端可随意挑选需要的算法. 设计模式之 Chain of Responsibility(责任链) 各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个. 设计模式之 Mediator(中介) Mediator 很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以. 设计模式之 State(状态) 状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换. 设计模式之 Memento(注释状态？) 很简单一个模式,就是在内存中保留原来数据的拷贝. 设计模式之 Interpreter(解释器) 主要用来对语言的分析,应用机会不多. 设计模式之 Visitor(访问者) 访问者在进行访问时,完成一系列实质性操作,而且还可以扩展. 设计模式引言 设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。你必须找到相关的对象，以适当的粒度将它们归 类，再定义类的接口和继承层次，建立对象之间的基本关系。你的设计应该对手头的问题有针对性，同时对将来的问题和需求 也要有足够的通用性。 你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你，要一下子就得到复用性和灵活性好的设计， 即使不是不可能的至少也是非常困难的。一个设计在最终完成之前常要被复用好几次，而且每一次都有所修改。 有经验的面向对象设计者的确能做出良好的设计，而新手则面对众多选择无从下手，总是求助于以前使用过的非面向对象 技术。新手需要花费较长时间领会良好的面向对象设计是怎么回事。有经验的设计者显然知道一些新手所不知道的东西，这又 是什么呢？ 内行的设计者知道：不是解决任何问题都要从头做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案，他 们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此，你会在许多面向对象系统中看到类和相互通信的对象（ c o m m u n i c a t i n go b j e c t）的重复模式。这些模式解决特定的设计问题，使面向对象设计更灵活、优雅，最终复用性更 好。它们帮助设计者将新的设计建立在以往工作的基础上，复用以往成功的设计方案。 一个熟悉这些模式的设计者不需要再去发现它们，而能够立即将它们应用于设计问题中。以下类比可以帮助说明这一点。 小说家和剧本作家很少从头开始设计剧情。他们总是沿袭一些业已存在的模式，像“悲剧性英雄”模式(《麦克白》、《哈姆雷特》 等)或“浪漫小说”模式(存在着无数浪漫小说)。同样地，面向对象设计员也沿袭一些模式，像“用对象表示状态”和“修饰对象以便 于你能容易地添加/删除属性”等。一旦懂得了模式，许多设计决策自然而然就产生了。 我们都知道设计经验的重要价值。你曾经多少次有过这种感觉—你已经解决过了一个问题但就是不能确切知道是在什么地 方或怎么解决的？如果你能记起以前问题的细节和怎么解决它的，你就可以复用以前的经验而不需要重新发现它。然而，我们 并没有很好记录下可供他人使用的软件设计经验。 学习 GoF设计模式的重要性 著名的 EJB 领域顶尖的专家 Richard Monson-Haefel 在其个人网站:www.EJBNow.com 中极力推荐的 GoF 的《设计模式》,原文 如下: Design Patterns Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have suffered a very serious gap in your programming education that should be remedied immediately. 翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读 过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补! 可以这么说：GoF 设计模式是程序员真正掌握面向对象核心思想的必修课。虽然你可能已经通过了 SUN 的很多令人炫目的 技术认证，但是如果你没有学习掌握 GoF 设计模式，只能说明你还是一个技工。 在浏览《Thingking in Java》(第一版)时，你是不是觉得好象这还是一本 Java 基础语言书籍？但又不纯粹是，因为这本书的作 者将面向对象的思想巧妙的融合在 Java 的具体技术上，潜移默化的让你感觉到了一种新的语言和新的思想方式的诞生。 但是读完这本书，你对书中这些蕴含的思想也许需要一种更明晰更系统更透彻的了解和掌握，那么你就需要研读 GoF 的《设 计模式》了。 《Thingking in Java》(第一版中文)是这样描述设计模式的：他在由 Gamma, Helm 和 Johnson Vlissides 简称 Gang of Four(四人 帮),缩写 GoF 编著的《Design Patterns》一书中被定义成一个“里程碑”。事实上，那本书现在已成为几乎所有 OOP(面向对象程 序设计)程序员都必备的参考书。(在国外是如此)。 GoF 的《设计模式》是所有面向对象语言(C++ Java C#)的基础，只不过不同的语言将之实现得更方便地使用。 GOF 的设计模式是一座"桥" 就 Java 语言体系来说，GOF 的设计模式是 Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。 会 Java 的人越来越多，但是一直徘徊在语言层次的程序员不在少数，真正掌握 Java 中接口或抽象类的应用不是很多，大家 经常以那些技术只适合大型项目为由，避开或忽略它们，实际中，Java 的接口或抽象类是真正体现 Java 思想的核心所在，这些 你都将在 GoF 的设计模式里领略到它们变幻无穷的魔力。 GoF 的设计模式表面上好象也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这 些好象和 J2EE .Net 等技术也无关！ 实际上，GoF 的设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用 和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的 Java 语言基础上跃进一步，更重要的是，GoF 的设计模式反复 向你强调一个宗旨：要让你的程序尽可能的可重用。 这其实在向一个极限挑战：软件需求变幻无穷，计划没有变化快，但是我们还是要寻找出不变的东西，并将它和变化的东 西分离开来，这需要非常的智慧和经验。 而 GoF 的设计模式是在这方面开始探索的一块里程碑。 J2EE 等属于一种框架软件，什么是框架软件？它不同于我们以前接触的 Java API 等，那些属于 Toolkist(工具箱)，它不再被动 的被使用，被调用，而是深刻的介入到一个领域中去，J2EE 等框架软件设计的目的是将一个领域中不变的东西先定义好，比如 整体结构和一些主要职责(如数据库操作 事务跟踪 安全等)，剩余的就是变化的东西，针对这个领域中具体应用产生的具体不同 的变化需求，而这些变化东西就是 J2EE 程序员所要做的。 由此可见，设计模式和 J2EE 在思想和动机上是一脉相承，只不过 1.设计模式更抽象，J2EE 是具体的产品代码，我们可以接触到，而设计模式在对每个应用时才会产生具体代码。 2.设计模式是比 J2EE 等框架软件更小的体系结构，J2EE 中许多具体程序都是应用设计模式来完成的，当你深入到 J2EE 的内 部代码研究时，这点尤其明显，因此，如果你不具备设计模式的基础知识(GoF 的设计模式)，你很难快速的理解 J2EE。不能理解 J2EE,如何能灵活应用？ 3.J2EE 只是适合企业计算应用的框架软件，但是 GoF 的设计模式几乎可以用于任何应用！因此 GoF 的设计模式应该是 J2EE 的重要理论基础之一。 所以说，GoF 的设计模式是 Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。为什么说隐性的？ GOF 的设计模式是一座隐性的"桥" 因为很多人没有注意到这点，学完 Java 基础语言就直接去学 J2EE,有的甚至鸭子赶架，直接使用起 Weblogic 等具体 J2EE 软 件，一段时间下来，发现不过如此，挺简单好用，但是你真正理解 J2EE 了吗？你在具体案例中的应用是否也是在延伸 J2EE 的思 想？ 如果你不能很好的延伸 J2EE 的思想，那你岂非是大炮轰蚊子，认识到 J2EE 不是适合所有场合的人至少是明智的，但我们更 需要将 J2EE 用对地方，那么只有理解 J2EE 此类框架软件的精髓，那么你才能真正灵活应用 Java 解决你的问题，甚至构架出你自 己企业的框架来。(我们不能总是使用别人设定好的框架，为什么不能有我们自己的框架？) 因此，首先你必须掌握 GoF 的设计模式。虽然它是隐性，但不是可以越过的。 关于本站“设计模式” Java 提供了丰富的 API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用， 甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至. 在真正可复用的面向对象编程中,GoF 的《设计模式》为我们提供了一套可复用的面向对象技术,再配合 Refactoring(重构方法), 所以很少存在简单重复的工作,加上Java 代码的精炼性和面向对象纯洁性(设计模式是 java 的灵魂),编程工作将变成一个让你时刻 体验创造快感的激动人心的过程. 为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解 GoF 的《设计模式》。由 于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此, 本站所有实例都是非图形应用,并且顺带剖析 Jive论坛系统.同时为降低理解难度，尽量避免使用 UML 图. 如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就 培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀 程序员的必备条件. 整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性. 建筑和软件中模式之异同 CSDN 的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式"写了专门文章《探寻软件的永恒 之道 》,其中很多观点我看了很受启发,以前我也将"设计模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软 件中地位,下面是我自己的一些想法: 建筑和软件某些地方是可以来比喻的 特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套路;中国画,也有套路,树应该怎么画 法?有几种画法?艺术大家通常是创造出自己的套路,比如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔 下去,浓淡几个叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来. 我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠. 再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北两派,大家有个感觉,旅游时,到南 方,你发现古代名居建筑都差不多;北方由于受满人等少数民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多. 这些都是模式的体现. 由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同. 正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这点,就产生了可以大量使用"软件 蓝领"的想法,因为他羡慕建筑中"民工"的低成本. 要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化,竞争激烈,所有一切变幻莫测,要应 付所有这些变化,首推信息技术中的软件,只有软件能够帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去 应付变化的,(它自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软件吧). 软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不一样了,建筑中的模式产生可以因 为很多原因:建筑大师的创意;材料的革新等;建筑中这些模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展, 因为很多人会不思创造,反复使用老的模式进行设计,阻碍建筑的发展. 但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担,将一些不变的东西先用模式固化,这 样让人类可以更加集中精力对付变化的东西,所以在软件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如J2EE), 不但没阻碍软件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在对付那些无法用模式的 应用上来. 可以关于建筑和软件中的模式作用可以总结如下: 在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的武器:人的思维,特别是创造 分析思 维等等，这些是软件真正的灵魂，这种思维可以说只要有实践需求(如有新项目)就要求发生，发生频度高，人类的创造或分析思 维决定了软件的质量和特点。 而在建筑中,模式可以构成建筑全部知识，当有新的需求(如有新项目)，一般使用旧的模式都可以完成，因此对人类的创造以 及分析思维不是每个项目都必须的，也不是非常重要的，对创造性的思维的需求只是属于锦上添花（除非人类以后离开地球居 住了〕。 设计模式之 Singleton(单态) 模式实战书籍《Java实用系统开发指南》 单态定义: Singleton 模式主要作用是保证在 Java 应用程序中，一个类 Class 只有一个实例存在。 在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。 还有, singleton 能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的 帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能 synchronize 的安全自动加 1，如果你要把这个数字 永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。 另外方面，Singleton 也能够被无状态化。提供工具性质的功能， Singleton 模式就为我们提供了这样实现的可能。使用 Singleton 的好处还在于可以节省内存，因为它限制了实例的个数，有 利于 Java 垃圾回收（garbage collection）。 我们常常看到工厂模式中类装入器(class loader)中也用 Singleton 模式实现的,因为被装入的类实际也属于资源。 如何使用? 一般 Singleton 模式通常有几种形式: public class Singleton { private Singleton(){} //在自己内部定义自己一个实例，是不是很奇怪？ //注意这是 private 只供内部调用 private static Singleton instance = new Singleton(); //这里提供了一个供外部访问本 class 的静态方法，可以直接访问 public static Singleton getInstance() { return instance; } } 第二种形式: public class Singleton { private static Singleton instance = null; public static synchronized Singleton getInstance() { //这个方法比上面有所改进，不用每次都进行生成对象，只是第一次 //使用时生成实例，提高了效率！ if (instance==null) instance＝new Singleton(); return instance; } } 使用 Singleton.getInstance()可以访问单态类。 上面第二中形式是 lazy initialization，也就是说第一次调用时初始 Singleton，以后就不用再生成了。 注意到 lazy initialization 形式中的 synchronized，这个 synchronized 很重要，如果没有 synchronized，那么使用 getInstance() 是有可能得到多个 Singleton 实例。关于 lazy initialization 的 Singleton 有很多涉及 double-checked locking (DCL)的讨论，有兴趣者 进一步研究。 一般认为第一种形式要更加安全些。 使用 Singleton 注意事项： 有时在某些情况下，使用 Singleton 并不能达到 Singleton 的目的，如有多个 Singleton 对象同时被不同的类装入器装载；在 EJB 这样的分布式系统中使用也要注意这种情况，因为 EJB 是跨服务器，跨 JVM 的。 我们以 SUN 公司的宠物店源码(Pet Store 1.3.1)的 ServiceLocator 为例稍微分析一下： 在 Pet Store中 ServiceLocator 有两种，一个是 EJB 目录下；一个是 WEB 目录下，我们检查这两个 ServiceLocator 会发现内容 差不多，都是提供 EJB 的查询定位服务，可是为什么要分开呢？仔细研究对这两种 ServiceLocator 才发现区别：在 WEB 中的 ServiceLocator 的采取 Singleton 模式，ServiceLocator 属于资源定位，理所当然应该使用 Singleton 模式。但是在 EJB 中，Singleton 模式已经失去作用，所以 ServiceLocator 才分成两种，一种面向 WEB 服务的，一种是面向 EJB 服务的。 Singleton 模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对 Java 的类 线程 内存等概念有相当 的了解。 总之：如果你的应用基于容器，那么 Singleton 模式少用或者不用，可以使用相关替代技术。 进一步深入可参考： Double-checked locking and the Singleton pattern When is a singleton not a singleton? 设计模式如何在具体项目中应用见《Java 实用系统开发指南》。 设计模式之 Factory 工厂模式定义:提供创建对象的接口. 为何使用? 工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。 为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的 new，我们经常要根据类 Class 生成实例对象，如 A a=new A() 工厂模式也是用来创建实例对象的，所以以后 new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做， 可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。 我们以类 Sample为例， 如果我们要创建 Sample的实例对象: Sample sample=new Sample(); 可是，实际情况是，通常我们都要在创建 sample实例时做点初始化的工作,比如赋值 查询数据库等。 首先，我们想到的是，可以使用 Sample的构造函数，这样生成实例就写成: Sample sample=new Sample(参数); 但是，如果创建 sample 实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数 中，那你的代码很难看了（就需要 Refactor 重整）。 为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多， 将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于 Java 面向对象的原则，面向对象 的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段 之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。 在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从 Sample的构造函数中分离出去。 这时我们就需要 Factory 工厂模式来生成对象了，不能再用上面简单 new Sample(参数)。还有,如果 Sample 有个继承 如 MySample, 按照面向接口编程,我们需要将 Sample 抽象成一个接口.现在 Sample 是接口,有两个子类 MySample 和 HisSample .我们要实例化他们时,如下: Sample mysample=new MySample(); Sample hissample=new HisSample(); 随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以 前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的. 但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了. 工厂方法 你会建立一个专门生产 Sample实例的工厂: public class Factory{ public static Sample creator(int which){ //getClass 产生 Sample 一般可使用动态类装载装入类。 if (which==1) return new SampleA(); else if (which==2) return new SampleB(); } } 那么在你的程序中,如果要实例化 Sample 时.就使用 Sample sampleA=Factory.creator(1); 这样,在整个就不涉及到 Sample 的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻: 就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可 能性就越少.好象我们从编程序中也能悟出人生道理?呵呵. 使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的 Sample,产品接口下有 Sample接口的实现类,如 SampleA,其次要有一个 factory 类，用来生成产品 Sample，如下图，最右边是生产的对象 Sample： 进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类 concreteFactory 了。 抽象工厂 工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory). 这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象 Sample,如果我们还有新的产品接口 Sample2. 这里假设：Sample有两个 concrete 类 SampleA 和 SamleB，而 Sample2 也有两个 concrete类 Sample2A 和 SampleB2 那么，我们就将上例中 Factory 变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的 Factory 拓展成抽象工厂: public abstract class Factory{ public abstract Sample creator(); public abstract Sample2 creator(String name); } public class SimpleFactory extends Factory{ public Sample creator(){ ......... return new SampleA } public Sample2 creator(String name){ ......... return new Sample2A } } public class BombFactory extends Factory{ public Sample creator(){ ...... return new SampleB } public Sample2 creator(String name){ ...... return new Sample2B } } 从上面看到两个工厂各自生产出一套 Sample和 Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产 Sample和 Sample2? 抽象工厂还有另外一个关键要点，是因为 SimpleFactory 内，生产 Sample和生产 Sample2 的方法之间有一定联系， 所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以 名称叫 SimpleFactory。 在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用， 举例 我们以 Jive的 ForumFactory 为例，这个例子在前面的 Singleton 模式中我们讨论过，现在再讨论其工厂模式: public abstract class ForumFactory { private static Object initLock = new Object(); private static String className = "com.jivesoftware.forum.database.DbForumFactory"; private static ForumFactory factory = null; public static ForumFactory getInstance(Authorization authorization) { //If no valid authorization passed in, return null. if (authorization == null) { return null; } //以下使用了 Singleton 单态模式 if (factory == null) { synchronized(initLock) { if (factory == null) { ...... try { //动态转载类 Class c = Class.forName(className); factory = (ForumFactory)c.newInstance(); } catch (Exception e) { return null; } } } } //Now, 返回 proxy.用来限制授权对 forum 的访问 return new ForumFactoryProxy(authorization, factory, factory.getPermissions(authorization)); } //真正创建 forum 的方法由继承 forumfactory 的子类去完成. public abstract Forum createForum(String name, String description) throws UnauthorizedException, ForumAlreadyExistsException; .... } 因为现在的 Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法 ForumFactory 就提供了提供动态接口: private static String className = "com.jivesoftware.forum.database.DbForumFactory"; 你可以使用自己开发的创建 forum 的方法代替 com.jivesoftware.forum.database.DbForumFactory 就可以. 在上面的一段代码中一共用了三种模式,除了工厂模式外,还有 Singleton 单态模式,以及 proxy模式,proxy 模式主要用来 授权用户对 forum 的访问,因为访问 forum 有两种人:一个是注册用户 一个是游客 guest,那么那么相应的权限就不一样,而且 这个权限是贯穿整个系统的,因此建立一个 proxy,类似网关的概念,可以很好的达到这个效果. 看看 Java 宠物店中的 CatalogDAOFactory: public class CatalogDAOFactory { /** * 本方法制定一个特别的子类来实现 DAO 模式。 * 具体子类定义是在 J2EE 的部署描述器中。 */ public static CatalogDAO getDAO() throws CatalogDAOSysException { CatalogDAO catDao = null; try { InitialContext ic = new InitialContext(); //动态装入 CATALOG_DAO_CLASS //可以定义自己的 CATALOG_DAO_CLASS，从而在无需变更太多代码 //的前提下，完成系统的巨大变更。 String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS); catDao = (CatalogDAO) Class.forName(className).newInstance(); } catch (NamingException ne) { throw new CatalogDAOSysException(" CatalogDAOFactory.getDAO: NamingException while getting DAO type : \n" + ne.getMessage()); } catch (Exception se) { throw new CatalogDAOSysException(" CatalogDAOFactory.getDAO: Exception while getting DAO type : \n" + se.getMessage()); } return catDao; } } CatalogDAOFactory 是典型的工厂方法， catDao 是通过动态类装入器 className 获得 CatalogDAOFactory 具体实现 子类，这个实现子类在 Java 宠物店是用来操作 catalog 数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类， 将自己的子类名给与 CATALOG_DAO_CLASS 变量就可以。 由此可见，工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制，只要我们更换一下具体的工厂方法，系统其他 地方无需一点变换，就有可能将系统功能进行改头换面的变化。 设计模式之 Builder Builder 模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. Builder 模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知 道内部的具体构建细节.Builder 模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到. 为何使用? 是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件. 因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但 远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder 模式就是为了将部件和组装 过程分开. 如何使用? 首先假设一个复杂对象是由多个部件组成的,Builder 模式是把复杂对象的创建和部件的创建分别开来,分别用 Builder 类和 Director 类来表示. 首先,需要一个接口,它定义如何创建复杂对象的各个部件: public interface Builder { //创建部件 A 比如创建汽车车轮 void buildPartA(); //创建部件 B 比如创建汽车方向盘 void buildPartB(); //创建部件 C 比如创建汽车发动机 void buildPartC(); //返回最后组装成品结果 (返回最后装配好的汽车) //成品的组装过程不在这里进行,而是转移到下面的 Director 类中进行. //从而实现了解耦过程和部件 Product getResult(); } 用 Director 构建最后的复杂对象,而在上面 Builder 接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就 是说 Director 的内容是如何将部件最后组装成成品: public class Director { private Builder builder; public Director( Builder builder ) { this.builder = builder; } // 将部件 partA partB partC 最后组成复杂对象 //这里是将车轮 方向盘和发动机组装成汽车的过程 public void construct() { builder.buildPartA(); builder.buildPartB(); builder.buildPartC(); } } Builder 的具体实现 ConcreteBuilder: 通过具体完成接口 Builder 来构建或装配产品的部件; 定义并明确它所要创建的是什么具体东西; 提供一个可以重新获取产品的接口: public class ConcreteBuilder implements Builder { Part partA, partB, partC; public void buildPartA() { //这里是具体如何构建 partA 的代码 }; public void buildPartB() { //这里是具体如何构建 partB 的代码 }; public void buildPartC() { //这里是具体如何构建 partB 的代码 }; public Product getResult() { //返回最后组装成品结果 }; } 复杂对象:产品 Product: public interface Product { } 复杂对象的部件: public interface Part { } 我们看看如何调用 Builder 模式: ConcreteBuilder builder = new ConcreteBuilder(); Director director = new Director( builder ); director.construct(); Product product = builder.getResult(); Builder 模式的应用 在 Java 实际使用中,我们经常用到"池"(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共 享时,就需要使用池. "池"实际是一段内存,当池中有一些复杂的资源的"断肢"(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这 些"断肢",将提高内存使用效率,提高池的性能.修改 Builder 模式中 Director 类使之能诊断"断肢"断在哪个部件上,再修复这个部件. 设计模式之 Prototype(原型) 原型模式定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象. Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个 原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。 如何使用? 因为 Java 中的提供 clone()方法来实现对象的克隆,所以 Prototype模式实现一下子变得很简单. 以勺子为例： public abstract class AbstractSpoon implements Cloneable { String spoonName; public void setSpoonName(String spoonName) {this.spoonName = spoonName;} public String getSpoonName() {return this.spoonName;} public Object clone() { Object object = null; try { object = super.clone(); } catch (CloneNotSupportedException exception) { System.err.println("AbstractSpoon is not Cloneable"); } return object; } } 有个具体实现(ConcretePrototype): public class SoupSpoon extends AbstractSpoon { public SoupSpoon() { setSpoonName("Soup Spoon"); } } 调用 Prototype 模式很简单: AbstractSpoon spoon = new SoupSpoon(); AbstractSpoon spoon2 = spoon.clone(); 当然也可以结合工厂模式来创建 AbstractSpoon 实例。 在 Java 中 Prototype 模式变成 clone()方法的使用，由于 Java 的纯洁的面向对象特性，使得在 Java 中使用设计模式变 得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如 Interator 遍历模式。 设计模式之 Adapter(适配器) 适配器模式定义: 将两个不兼容的类纠合在一起使用，属于结构型模式,需要有 Adaptee(被适配者)和 Adaptor(适配器)两个身份. 为何使用? 我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或 者，我们不愿意为了一个应用而修改各自的接口。 怎么办? 使用 Adapter，在这两种接口之间创建一个混合接口(混血儿). 如何使用? 实现 Adapter 方式,其实"think in Java"的"类再生"一节中已经提到,有两种方式：组合(composition)和继承 (inheritance). 假设我们要打桩，有两种类：方形桩 圆形桩. public class SquarePeg{ public void insert(String str){ System.out.println("SquarePeg insert():"+str); } } public class RoundPeg{ public void insertIntohole(String msg){ System.out.println("RoundPeg insertIntoHole():"+msg); } } 现在有一个应用,需要既打方形桩,又打圆形桩.那么我们需要将这两个没有关系的类综合应用.假设 RoundPeg 我们没有源 代码,或源代码我们不想修改,那么我们使用 Adapter 来实现这个应用: public class PegAdapter extends SquarePeg{ private RoundPeg roundPeg; public PegAdapter(RoundPeg peg)(this.roundPeg=peg;) public void insert(String str){ roundPeg.insertIntoHole(str);} } 在上面代码中,RoundPeg 属于 Adaptee,是被适配者.PegAdapter 是 Adapter,将 Adaptee(被适配者 RoundPeg)和 Target(目标 SquarePeg)进行适配.实际上这是将组合方法(composition)和继承(inheritance)方法综合运用. PegAdapter 首先继承 SquarePeg，然后使用 new 的组合生成对象方式，生成 RoundPeg 的对象 roundPeg，再重载父 类 insert()方法。从这里,你也了解使用 new生成对象和使用 extends 继承生成对象的不同,前者无需对原来的类修改,甚至无 需要知道其内部结构和源代码. 如果你有些 Java 使用的经验，已经发现，这种模式经常使用。 进一步使用 上面的 PegAdapter 是继承了 SquarePeg,如果我们需要两边继承，即继承 SquarePeg 又继承 RoundPeg,因为 Java 中 不允许多继承，但是我们可以实现(implements)两个接口(interface) public interface IRoundPeg{ public void insertIntoHole(String msg); } public interface ISquarePeg{ public void insert(String str); } 下面是新的 RoundPeg 和 SquarePeg, 除了实现接口这一区别，和上面的没什么区别。 public class SquarePeg implements ISquarePeg{ public void insert(String str){ System.out.println("SquarePeg insert():"+str); } } public class RoundPeg implements IRoundPeg{ public void insertIntohole(String msg){ System.out.println("RoundPeg insertIntoHole():"+msg); } } 下面是新的 PegAdapter,叫做 two-way adapter: public class PegAdapter implements IRoundPeg,ISquarePeg{ private RoundPeg roundPeg; private SquarePeg squarePeg; // 构造方法 public PegAdapter(RoundPeg peg){this.roundPeg=peg;} // 构造方法 public PegAdapter(SquarePeg peg)(this.squarePeg=peg;) public void insert(String str){ roundPeg.insertIntoHole(str);} } 还有一种叫 Pluggable Adapters,可以动态的获取几个 adapters 中一个。使用 Reflection 技术，可以动态的发现类中的 Public 方法。 设计模式之 Proxy(代理) 理解并使用设计模式,能够培养我们良好的面向对象编程习惯,同时在实际应用中,可以如鱼得水,享受游刃有余的乐趣. 代理模式是比较有用途的一种模式,而且变种较多,应用场合覆盖从小结构到整个系统的大结构,Proxy 是代理的意思,我们 也许有代理服务器等概念,代理概念可以解释为:在出发点到目的地之间有一道中间层,意为代理. 设计模式中定义: 为其他对象提供一种代理以控制对这个对象的访问. 为什么要使用 Proxy? 1.授权机制 不同级别的用户对同一对象拥有不同的访问权利,如 Jive 论坛系统中,就使用 Proxy 进行授权机制控制,访问 论坛有两种人:注册用户和游客(未注册用户),Jive 中就通过类似 ForumProxy 这样的代理来控制这两种用户对论坛的访问权 限. 2.某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动. 举例两个具体情况: (1)如果那个对象是一个是很大的图片,需要花费很长时间才能显示出来,那么当这个图片包含在文档中时,使用编辑器或浏 览器打开这个文档,打开文档必须很迅速,不能等待大图片处理完成,这时需要做个图片 Proxy 来代替真正的图片. (2)如果那个对象在 Internet 的某个远端服务器上,直接操作这个对象因为网络速度原因可能比较慢,那我们可以先用 Proxy来代替那个对象. 总之原则是,对于开销很大的对象,只有在使用它时才创建,这个原则可以为我们节省很多宝贵的 Java 内存. 所以,有些人认 为 Java 耗费资源内存,我以为这和程序编制思路也有一定的关系. 如何使用 Proxy? 以 Jive 论坛系统为例,访问论坛系统的用户有多种类型:注册普通用户 论坛管理者 系统管理者 游客,注册普通用户才能发 言;论坛管理者可以管理他被授权的论坛;系统管理者可以管理所有事务等,这些权限划分和管理是使用 Proxy完成的. Forum 是 Jive的核心接口,在 Forum 中陈列了有关论坛操作的主要行为,如论坛名称 论坛描述的获取和修改,帖子发表删 除编辑等. 在 ForumPermissions 中定义了各种级别权限的用户: public class ForumPermissions implements Cacheable { /** * Permission to read object. */ public static final int READ = 0; /** * Permission to administer the entire sytem. */ public static final int SYSTEM_ADMIN = 1; /** * Permission to administer a particular forum. */ public static final int FORUM_ADMIN = 2; /** * Permission to administer a particular user. */ public static final int USER_ADMIN = 3; /** * Permission to administer a particular group. */ public static final int GROUP_ADMIN = 4; /** * Permission to moderate threads. */ public static final int MODERATE_THREADS = 5; /** * Permission to create a new thread. */ public static final int CREATE_THREAD = 6; /** * Permission to create a new message. */ public static final int CREATE_MESSAGE = 7; /** * Permission to moderate messages. */ public static final int MODERATE_MESSAGES = 8; ..... public boolean isSystemOrForumAdmin() { return (values[FORUM_ADMIN] || values[SYSTEM_ADMIN]); } ..... } 因此,Forum 中各种操作权限是和 ForumPermissions 定义的用户级别有关系的,作为接口 Forum 的实现:ForumProxy 正是将这种对应关系联系起来.比如,修改 Forum 的名称,只有论坛管理者或系统管理者可以修改,代码如下: public class ForumProxy implements Forum { private ForumPermissions permissions; private Forum forum; this.authorization = authorization; public ForumProxy(Forum forum, Authorization authorization, ForumPermissions permissions) { this.forum = forum; this.authorization = authorization; this.permissions = permissions; } ..... public void setName(String name) throws UnauthorizedException, ForumAlreadyExistsException { //只有是系统或论坛管理者才可以修改名称 if (permissions.isSystemOrForumAdmin()) { forum.setName(name); } else { throw new UnauthorizedException(); } } ... } 而 DbForum 才是接口 Forum 的真正实现,以修改论坛名称为例: public class DbForum implements Forum, Cacheable { ... public void setName(String name) throws ForumAlreadyExistsException { .... this.name = name; //这里真正将新名称保存到数据库中 saveToDb(); .... } ... } 凡是涉及到对论坛名称修改这一事件,其他程序都首先得和ForumProxy打交道,由ForumProxy决定是否有权限做某一样 事情,ForumProxy 是个名副其实的"网关","安全代理系统". 在平时应用中,无可避免总要涉及到系统的授权或安全体系,不管你有无意识的使用 Proxy,实际你已经在使用 Proxy了. 我们继续结合 Jive谈入深一点,下面要涉及到工厂模式了,如果你不了解工厂模式,请看我的另外一篇文章:设计模式之 Factory 我们已经知道,使用 Forum 需要通过 ForumProxy,Jive 中创建一个 Forum 是使用 Factory 模式,有一个总的抽象类 ForumFactory,在这个抽象类中,调用 ForumFactory 是通过 getInstance()方法实现,这里使用了 Singleton(也是设计模式 之一,由于介绍文章很多,我就不写了),getInstance()返回的是 ForumFactoryProxy. 为什么不返回 ForumFactory,而返回 ForumFactory 的实现 ForumFactoryProxy? 原因是明显的,需要通过代理确定是否有权限创建 forum. 在 ForumFactoryProxy 中我们看到代码如下: public class ForumFactoryProxy extends ForumFactory { protected ForumFactory factory; protected Authorization authorization; protected ForumPermissions permissions; public ForumFactoryProxy(Authorization authorization, ForumFactory factory, ForumPermissions permissions) { this.factory = factory; this.authorization = authorization; this.permissions = permissions; } public Forum createForum(String name, String description) throws UnauthorizedException, ForumAlreadyExistsException { //只有系统管理者才可以创建 forum if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) { Forum newForum = factory.createForum(name, description); return new ForumProxy(newForum, authorization, permissions); } else { throw new UnauthorizedException(); } } 方法 createForum 返回的也是 ForumProxy, Proxy 就象一道墙,其他程序只能和 Proxy交互操作. 注意到这里有两个 Proxy:ForumProxy 和 ForumFactoryProxy. 代表两个不同的职责:使用 Forum 和创建 Forum; 至于为什么将使用对象和创建对象分开,这也是为什么使用 Factory 模式的原因所在:是为了"封装" "分派";换句话说,尽可 能功能单一化,方便维护修改. Jive论坛系统中其他如帖子的创建和使用,都是按照 Forum 这个思路而来的. 以上我们讨论了如何使用Proxy进行授权机制的访问,Proxy还可以对用户隐藏另外一种称为copy-on-write的优化方式. 拷贝一个庞大而复杂的对象是一个开销很大的操作,如果拷贝过程中,没有对原来的对象有所修改,那么这样的拷贝开销就没有必 要.用代理延迟这一拷贝过程. 比如:我们有一个很大的 Collection,具体如 hashtable,有很多客户端会并发同时访问它.其中一个特别的客户端要进行连 续的数据获取,此时要求其他客户端不能再向 hashtable 中增加或删除 东东. 最直接的解决方案是:使用 collection 的 lock,让这特别的客户端获得这个 lock,进行连续的数据获取,然后再释放 lock. public void foFetches(Hashtable ht){ synchronized(ht){ //具体的连续数据获取动作.. } } 但是这一办法可能锁住 Collection 会很长时间,这段时间,其他客户端就不能访问该 Collection 了. 第二个解决方案是clone这个Collection,然后让连续的数据获取针对clone出来的那个Collection操作.这个方案前提是, 这个 Collection 是可 clone的,而且必须有提供深度 clone的方法.Hashtable 就提供了对自己的 clone方法,但不是 Key和 value对象的 clone,关于 Clone含义可以参考专门文章. public void foFetches(Hashtable ht){ Hashttable newht=(Hashtable)ht.clone(); } 问题又来了,由于是针对clone出来的对象操作,如果原来的母体被其他客户端操作修改了, 那么对clone出来的对象操作就 没有意义了. 最后解决方案:我们可以等其他客户端修改完成后再进行 clone,也就是说,这个特别的客户端先通过调用一个叫 clone的方 法来进行一系列数据获取操作.但实际上没有真正的进行对象拷贝,直至有其他客户端修改了这个对象 Collection. 使用 Proxy实现这个方案.这就是 copy-on-write操作. Proxy应用范围很广,现在流行的分布计算方式 RMI 和 Corba 等都是 Proxy模式的应用. 更多 Proxy应用,见 http://www.research.umbc.edu/~tarr/cs491/lectures/Proxy.pdf Sun 公司的 Explore the Dynamic Proxy API Dynamic Proxy Classes 设计模式之 Facade(外观 总管 Manager) Facade 模式的定义: 为子系统中的一组接口提供一个一致的界面. Facade一个典型应用就是数据库 JDBC 的应用,如下例对数据库的操作: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "" ).newInstance(); conn = DriverManager.getConnection( "" ); String sql = "SELECT * FROM WHERE = ?"; prep = conn.prepareStatement( sql ); prep.setString( 1, "" ); rset = prep.executeQuery(); if( rset.next() ) { System.out.println( rset.getString( "应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象 的方法被调用执行时，Composite 将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一 动百来形容。 所以 Composite 模式使用到 Iterator 模式，和 Chain of Responsibility 模式类似。 Composite 好处: 1.使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关系自己处理的是单个对象还是整个 组合结构，这就简化了客户端代码。 2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。 如何使用 Composite? 首先定义一个接口或抽象类，这是设计模式通用方式了，其他设计模式对接口内部定义限制不多， Composite 却有个规定， 那就是要在接口内部定义一个用于访问和管理 Composite组合体的对象们（或称部件 Component）. 下面的代码是以抽象类定义，一般尽量用接口 interface, public abstract class Equipment { private String name; //实价 public abstract double netPrice(); //折扣价格 public abstract double discountPrice(); //增加部件方法 public boolean add(Equipment equipment) { return false; } //删除部件方法 public boolean remove(Equipment equipment) { return false; } //注意这里，这里就提供一种用于访问组合体类的部件方法。 public Iterator iter() { return null; } public Equipment(final String name) { this.name=name; } } 抽象类 Equipment 就是 Component 定义，代表着组合体类的对象们,Equipment 中定义几个共同的方法。 public class Disk extends Equipment { public Disk(String name) { super(name); } //定义 Disk 实价为 1 public double netPrice() { return 1.; } //定义了 disk 折扣价格是 0.5 对折。 public double discountPrice() { return .5; } } Disk是组合体内的一个对象，或称一个部件，这个部件是个单独元素( Primitive)。 还有一种可能是，一个部件也是一个组合体，就是说这个部件下面还有'儿子'，这是树形结构中通常的情况，应该比较容易理解。 现在我们先要定义这个组合体： abstract class CompositeEquipment extends Equipment { private int i=0; //定义一个 Vector 用来存放'儿子' private Lsit equipment=new ArrayList(); public CompositeEquipment(String name) { super(name); } public boolean add(Equipment equipment) { this.equipment.add(equipment); return true; } public double netPrice() { double netPrice=0.; Iterator iter=equipment.iterator(); for(iter.hasNext()) netPrice+=((Equipment)iter.next()).netPrice(); return netPrice; } public double discountPrice() { double discountPrice=0.; Iterator iter=equipment.iterator(); for(iter.hasNext()) discountPrice+=((Equipment)iter.next()).discountPrice(); return discountPrice; } //注意这里，这里就提供用于访问自己组合体内的部件方法。 //上面 dIsk 之所以没有，是因为 Disk 是个单独(Primitive)的元素. public Iterator iter() { return equipment.iterator() ; { //重载 Iterator 方法 public boolean hasNext() { return i小设备，如硬盘 软驱等。无疑这两个都是属于组合体性质的。 public class Chassis extends CompositeEquipment { public Chassis(String name) { super(name); } public double netPrice() { return 1.+super.netPrice(); } public double discountPrice() { return .5+super.discountPrice(); } } public class Cabinet extends CompositeEquipment { public Cabinet(String name) { super(name); } public double netPrice() { return 1.+super.netPrice(); } public double discountPrice() { return .5+super.discountPrice(); } } 至此我们完成了整个 Composite模式的架构。 我们可以看看客户端调用 Composote 代码: Cabinet cabinet=new Cabinet("Tower"); Chassis chassis=new Chassis("PC Chassis"); //将 PC Chassis 装到 Tower 中 (将盘盒装到箱子里) cabinet.add(chassis); //将一个 10GB 的硬盘装到 PC Chassis (将硬盘装到盘盒里) chassis.add(new Disk("10 GB")); //调用 netPrice()方法; System.out.println("netPrice="+cabinet.netPrice()); System.out.println("discountPrice="+cabinet.discountPrice()); 上面调用的方法 netPrice()或 discountPrice()，实际上 Composite 使用 Iterator 遍历了整个树形结构,寻找同样包含这 个方法的对象并实现调用执行. Composite是个很巧妙体现智慧的模式，在实际应用中，如果碰到树形结构，我们就可以尝试是否可以使用这个模式。 以论坛为例，一个版(forum)中有很多帖子(message),这些帖子有原始贴，有对原始贴的回应贴，是个典型的树形结构， 那么当然可以使用 Composite模式，那么我们进入 Jive中看看，是如何实现的. Jive 解剖 在 Jive中 ForumThread 是 ForumMessages 的容器 container(组合体).也就是说，ForumThread 类似我们上例中的 CompositeEquipment.它和 messages 的关系如图： [thread] |- [message] |- [message] |- [message] |- [message] |- [message] 我们在 ForumThread 看到如下代码： public interface ForumThread { .... public void addMessage(ForumMessage parentMessage, ForumMessage newMessage) throws UnauthorizedException; public void deleteMessage(ForumMessage message) throws UnauthorizedException; public Iterator messages(); .... } 类似 CompositeEquipment, 提供用于访问自己组合体内的部件方法: 增加 删除 遍历. 结合我的其他模式中对 Jive的分析，我们已经基本大体理解了 Jive 论坛体系的框架，如果你之前不理解设计模式，而直接去看 Jive源代码，你肯定无法看懂。 参考文章： Composite 模式和树形结构的讨论 设计模式之 Decorator(油漆工) 装饰模式:Decorator 常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的 对象我们称 decoratee.这两种实体在 Decorator 模式中是必须的. Decorator定义: 动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用 Decorator 模式相比用生成子类方式达到功能的扩充显得更为灵 活. 为什么使用 Decorator? 我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生成很多子类,增加系统的复杂性, 同时,使用继承实现功能拓展,我们必须可预见这些拓展功能,这些功能是编译时就确定了,是静态的. 使用Decorator的理由是:这些功能需要由用户动态决定加入的方式和时机.Decorator提供了"即插即用"的方法,在运行期间决 定何时增加何种功能. 如何使用? 举Adapter 中的打桩示例,在 Adapter 中有两种类:方形桩 圆形桩,Adapter模式展示如何综合使用这两个类,在Decorator模 式中,我们是要在打桩时增加一些额外功能,比如,挖坑 在桩上钉木板等,不关心如何使用两个不相关的类. 我们先建立一个接口: public interface Work { public void insert(); } 接口 Work有一个具体实现:插入方形桩或圆形桩,这两个区别对 Decorator 是无所谓.我们以插入方形桩为例: public class SquarePeg implements Work{ public void insert(){ System.out.println("方形桩插入"); } } 现在有一个应用:需要在桩打入前,挖坑,在打入后,在桩上钉木板,这些额外的功能是动态,可能随意增加调整修改,比如,可能又需 要在打桩之后钉架子(只是比喻). 那么我们使用 Decorator 模式,这里方形桩 SquarePeg 是 decoratee(被刷油漆者),我们需要在 decoratee 上刷些"油漆",这 些油漆就是那些额外的功能. public class Decorator implements Work{ private Work work; //额外增加的功能被打包在这个 List 中 private ArrayList others = new ArrayList(); //在构造器中使用组合 new方式,引入 Work 对象; public Decorator(Work work) { this.work=work; others.add("挖坑"); others.add("钉木板"); } public void insert(){ newMethod(); } //在新方法中,我们在 insert 之前增加其他方法,这里次序先后是用户灵活指定的 public void newMethod() { otherMethod(); work.insert(); } public void otherMethod() { ListIterator listIterator = others.listIterator(); while (listIterator.hasNext()) { System.out.println(((String)(listIterator.next())) + " 正在进行"); } } } 在上例中,我们把挖坑和钉木板都排在了打桩 insert 前面,这里只是举例说明额外功能次序可以任意安排. 好了,Decorator 模式出来了,我们看如何调用: Work squarePeg = new SquarePeg(); Work decorator = new Decorator(squarePeg); decorator.insert(); Decorator 模式至此完成. 如果你细心,会发现,上面调用类似我们读取文件时的调用: FileReader fr = new FileReader(filename); BufferedReader br = new BufferedReader(fr); 实际上 Java 的 I/O API 就是使用 Decorator 实现的,I/O变种很多,如果都采取继承方法,将会产生很多子类,显然相当繁琐. Jive 中的 Decorator 实现 在论坛系统中,有些特别的字是不能出现在论坛中如"打倒 XXX",我们需要过滤这些"反动"的字体.不让他们出现或者高亮度显 示. 在 IBM Java 专栏中专门谈 Jive的文章中,有谈及 Jive中 ForumMessageFilter.java 使用了 Decorator 模式,其实,该程序并 没有真正使用 Decorator,而是提示说:针对特别论坛可以设计额外增加的过滤功能,那么就可以重组 ForumMessageFilter 作 为 Decorator 模式了. 所以,我们在分辨是否真正是Decorator模式,以及会真正使用Decorator模式,一定要把握好Decorator模式的定义,以及其中 参与的角色(Decoratee 和 Decorator). 设计模式之 Bridge Bridge 模式定义 :将抽象和行为划分开来,各自独立,但能动态的结合。 任何事物对象都有抽象和行为之分，例如人，人是一种抽象，人分男人和女人等；人有行为，行为也有各种具体表现，所 以，“人”与“人的行为”两个概念也反映了抽象和行为之分。 在面向对象设计的基本概念中，对象这个概念实际是由属性和行为两个部分组成的，属性我们可以认为是一种静止的，是 一种抽象，一般情况下，行为是包含在一个对象中，但是，在有的情况下，我们需要将这些行为也进行归类，形成一个总的行 为接口，这就是桥模式的用处。 为什么使用? 不希望抽象部分和行为有一种固定的绑定关系，而是应该可以动态联系的。 如果一个抽象类或接口有多个具体实现(子类、concrete subclass),这些子类之间关系可能有以下两种情况: 1. 这多个子类之间概念是并列的,如前面举例,打桩,有两个 concrete class:方形桩和圆形桩;这两个形状上的桩是并列的, 没有概念上的重复。 2.这多个子类之中有内容概念上重叠.那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接 口里,现在需要设计两个接口：抽象接口和行为接口，分别放置抽象和行为. 例如,一杯咖啡为例,子类实现类为四个：中杯加奶、大杯加奶、 中杯不加奶、大杯不加奶。 但是，我们注意到：上面四个子类中有概念重叠，可从另外一个角度进行考虑，这四个类实际是两个角色的组合：抽象 和 行为，其中抽象为：中杯和大杯；行为为：加奶 不加奶（如加橙汁 加苹果汁）. 实现四个子类在抽象和行为之间发生了固定的绑定关系，如果以后动态增加加葡萄汁的行为，就必须再增加两个类：中杯 加葡萄汁和大杯加葡萄汁。显然混乱,扩展性极差。 那我们从分离抽象和行为的角度，使用 Bridge模式来实现。 如何实现?
让Oracle跑得更快：Oracle10g性能分析与优化思路--详细书签版
CruiseYoung提供的带有详细书签的电子书籍目录 http://blog.csdn.net/fksec/article/details/7888251 让Oracle跑得更快：Oracle10g性能分析与优化思路 本信息 作者： 谭怀远 丛书名： ITPUB技术丛书 出版社：电子工业出版社 ISBN：9787121113253 上架时间：2010-8-6 出版日期：2010 年8月 开本：16开 页码：438 版次：1-1 编辑推荐 　　 国内第一本真正意义上从工作经验出发，以作者的心得体会全面论述Oracle数据库性能优化的书籍。 　　 作者内心经历的表白，站在全局角度对性能做分析，而不是拘泥于具体的技术细节，呈现给读者一种新的阅读思路。 　　 书中涉及很多新的性能话题，比如执行计划，bind peeking，并行执行，10046及10053事件，AWR报告等,基本上涵盖了所有Oracle数据库性能方面的知识。 内容简介 　　在这本书里读者将会学到作者在性能优化方面的一些思路和思考，一些故障处理的方法和原则，这些东西是作者在实践中长期积累的心得体会，当读者掌握了一些处理问题的基本思路之后，成为一名合格的dba就是一件轻而易举的事情了。 　　本书适用对象：oracle dba、oracle开发人员，和其他对oracle数据库感兴趣的人员。 作译者 　　谭怀远，副总工，DBA团队负责人，在国内属于较早进入专职DBA岗位的人。是国内著名数据库论坛ITPUB的资深版主，论坛id alantany。有10年的Oracle DBA工作经验，从Oracle 8开始进入数据库领域，从Oracle 8到Oracle 8i,Oracle 9i,Oracle 10g，见证了中国DBA职业的发展历程。作者对数据库的性能优化有独到的见解，颇擅长于海量数据数据库的设计管理及优化工作。 目录 封面 -17 扉页 -16 版权 -15 序 -14 前言 -12 致谢 -5 目录 -4 第1章 引起数据库性能问题的因素 1 1.1 软件设计对数据库的影响 1 1.1.1 软件架构设计对数据库性能的影响 1 1.1.2 软件代码的编写对数据库性能的影响 2 1.2 数据库的设计 8 1.2.1 OLTP数据库 9 1.2.2 OLAP数据库 10 1.3 数据库的硬件设计 14 1.3.1 存储容量 15 1.3.2 存储的物理设计 16 1.3.3 数据的安全 17 1.4 小结 19 第2章 锁和阻塞 20 2.1 关于锁 20 2.2 锁和阻塞 22 2.3 引起阻塞的其他情况 30 2.3.1 select for update 30 2.3.2 外键和索引 36 第3章 Latch和等待 44 3.1 共享池中的Latch争用 45 3.2 数据缓冲池Latch争用 54 3.2.1 表数据块 54 3.2.2 索引数据块 59 3.2.3 索引根数据块 62 3.2.4 段头数据块 65 第4章 优化器 66 4.1 RBO基于规则的优化器 66 4.2 CBO基于成本的优化器 69 第5章 执行计划 85 5.1 Cardinality （基数） 85 5.2 SQL的执行计划 94 第6章 Hint 109 6.1 和优化器相关的Hint 115 6.1.1 all_rows和first_rows（CBO） 115 6.1.2 RULE Hint 117 6.2 访问路径相关的Hint 117 6.2.1 FULL Hint 118 6.2.2 INDEX Hint 118 6.2.3 NO_INDEX Hint 118 6.2.4 INDEX_DESC Hint 119 6.2.5 INDEX_COMBINE Hint 119 6.2.6 INDEX_FFS 119 6.2.7 INDEX_JOIN 120 6.2.8 INDEX_SS Hint 120 6.3 表关联顺序的Hint 125 6.3.1 LEADING Hint 125 6.3.2 ORDERED Hint 126 6.4 表关联操作的Hint 127 6.4.1 USE_HASH，USE_NL和USE_MERGE Hint 127 6.4.2 NO_USE_HASH Hint 132 6.4.3 NO_USE_MERGE Hint 133 6.4.4 NO_USE_NL Hint 133 6.5 并行执行相关的Hint 134 6.5.1 PARALLEL Hint 134 6.5.2 NO_PARALLEL Hint 134 6.6 其他方面的一些Hint 135 6.6.1 APPEND Hint 135 6.6.2 DYNAMIC_SAMPLING Hint 135 6.6.3 DRIVING_SITE Hint 136 6.6.4 CACHE Hint 136 6.7 小结 136 第7章 分析及动态采样 138 7.1 直方图 141 7.2 DBMS_STATS包 147 7.3 动态采样 176 7.3.1 什么是动态采样 176 7.3.2 动态采样的级别 182 7.3.3 什么时候使用动态采样？ 185 7.4 小结 185 第8章 并行执行 186 8.1 并行和OLAP系统 187 8.2 并行处理的机制 189 8.3 读懂一个并行处理的执行计划 191 8.4 一个很常见的并行执行等待事件 192 8.5 并行执行的适用范围 194 8.5.1 并行查询 194 8.5.2 并行DDL操作 195 8.5.3 并行DML操作 203 8.6 并行执行的设定 210 8.6.1 并行相关的初始化参数 210 8.6.2 并行度的设定 211 8.7 直接加载 213 8.7.1 直接加载和REDO 216 8.7.2 直接加载和索引 219 8.7.3 直接加载和并行 221 8.7.4 直接加载和SQL*LOADER 226 第9章 变量绑定 232 9.1 什么是变量绑定，为什么要做变量绑定 232 9.2 为什么说OLTP必须要求变量绑定而OLAP不应该绑定变量 241 9.3 bind peaking 248 第10章 SQL_TRACE和10046事件 254 10.1 SQL_TRACE 254 10.2 TKPROF工具 256 10.3 10046事件 268 第11章 10053事件 276 第12章 性能视图和性能参数 294 12.1 性能视图 294 12.1.1 V$SQL 295 12.1.2 V$SQL_SHARED_CURSOR 300 12.1.3 v$session 305 12.1.4 V$sessstat 309 12.1.5 V$session_wait 310 12.2 性能参数 312 12.2.1 Cursor_sharing 313 12.2.2 DB_FILE_MULTIBLOCK_READ_COUNT 328 12.2.3 PGA_AGGREGATE_TARGET和SGA_TARGET 334 12.2.4 OPTIMIZER_DYNAMIC_SAMPLING 334 第13章 性能报告 335 13.1 AWR性能报告 335 13.1.1 生成AWR性能报告 337 13.1.2 AWR性能报告分析 342 13.2 Statspack性能报告 386 13.2.1 Statspack的安装 386 13.2.2 Statspack性能采集 391 13.3 ASH性能报告 394 13.3.1 生成ASH性能报告 395 13.3.2 ASH性能报告分析 405 13.4 小结 416 附录A 常见的等待事件 417 后记 关于数据库的学习方法 434 前言 　　笔者在写这本书的时候，翻看了很多当前国内数据库方面的书籍，发现写性能优化的书并不多，特别是从工作经验和思路上来讨论性能方面的书，更是少之又少，这些因素让笔者思考要写这样一本书，这也算是这本书的一个定位。 　　在这本书里，你将会学到笔者在性能优化方面的一些思路和思考，一些故障处理的方法和原则，这些东西是笔者在实践中长期积累的心得体会，在笔者看来，掌握处理问题的方法和分析问题的思路在日常工作中显得更为重要，当你掌握了一些处理问题的基本思路之后，剩下的工作就是去Google或者阅读参考书了。 　　本书的一个特点是，凡是作者提到的观点，都尽可能地使用一些例子来证明它，这样看起来更有说服力一些。 　　为什么会出现数据库的性能问题 　　性能问题是最近几年来DBA们越来越关注的一个数据库技术领域，归根结底，造成它的原因是最近几年信息化进程的飞速发展，导致了很多系统的用户数量猛增，数据库中存储的数据量亦成几何级数激增，数据库作为数据处理和存储的最终受体，将必然直接承担这种变化导致的性能下降。因此在人们对信息的依赖性越来越强的时候，对信息使用的效率也变得越来越关注，这样数据库的性能优化问题就日益严重地压在DBA的身上。 　　什么时候需要对性能进行干预 　　itpub.net是国内最早的一个专业讨论Oracle数据库技术的论坛，目前在国内数据库方面已经相当有知名度，笔者是2001年注册的，算是最早的会员之一。目前仍然会经常上去看看，由于工作内容的关系，我比较关注性能方面的帖子，发现以下一类的帖子经常有很多，比如： 　　1. 我是一个DBA，我现在手头有一个数据库，我该从哪里进行性能优化呢？ 　　2. 这是我的数据库的一个Statspack，我该如何优化？ 　　通常对于第一个问题，我是很少回答的，并不是不屑于回答，实在是没有办法回答，如果我回答说，“你怎么知道你的数据库需要优化？”又担心这种没有实际意义的回答带有说教意味，打击别人的积极性，所以通常看看而已。实际上我是想说，对于一个DBA来讲，当你拿到一个数据库的时候，你首先需要做的是用最短的时间来了解一下跑在这个库上的是一个什么系统，比如是在线事务（OLTP）系统还是在线分析（OLAP）系统，这对于你做出性能上的判断至关重要，如果连系统都不了解，真不知道该如何去优化它，这就好比说，要设计一辆汽车，如果连用户对汽车的喜好都弄不清楚，如何能设计出一个取悦于用户的车呢？ 　　对于第二个问题，像是比第一个具体一些，因为帖子作者已经提供了一个性能数据报告，但我仍然觉得通过这些数据没有办法准确地判断数据库是否有性能问题。比如你是一个医生，我让一个人站在你的面前测心率，结果是50次/分钟，你是不是可以断定他有问题，需要安装心脏起搏器呢？实际上是不需要，因为我知道他是一个运动员，这样的心率是正常的，而医生不知道，所以他在做出诊断之前需要详细了解站在自己面前的应诊者的所有详细信息，来作为他做出判断的依据。 　　下面贴出一个来自于我使用过的数据库性能报告中的一部分： 　　Buffer Nowait %: 100.00 Redo NoWait %: 99.99 　　Buffer Hit %: 66.35 In-memory Sort %: 100.00 　　Library Hit %: 99.63 Soft Parse %: 96.87 　　Execute to Parse %: 83.99 Latch Hit %: 99.87 　　Parse CPU to Parse Elapsd %: % Non-Parse CPU: 100.00 　　 　　许多人看到这个数据一定会大声说： 　　“嘿，你的数据库性能好差，buffer hit只有66%，不知道是谁设计的这个系统，赶紧加大data buffer的尺寸!” .　　 　　诚然，这个数据的确显示数据库的内存命中率低得可怜，但是我想告诉你的是，这是一个在线分析（OLAP）系统的数据库，运行着很多非常大的查询，每个查询搜索的范围都在上亿条记录以上，那这个结果不是很正常吗？我们需要把几亿条数据缓存到内存里提供给这种每天可能只运行几次的查询吗？你可以同意，但是你的老板是不会同意的，这样做的成本太高了，而且完全没有必要，因为它只是一个报表系统，对数据库的响应时间要求不高，所以我们当然可以让这个查询直接到磁盘上去搜索数据，这也就是为什么在这样的系统里，buffer hit比例很低，但却是一个完全可以接受的值的原因。 　　笔者认为，只有数据库的性能已经影响到业务的正常工作或者用户已经无法满意于这种性能时，我们才应该考虑来优化它，对于绝大多数系统，数据库的安全和稳定才是最重要的。 　　FAST=TRUE？ 　　这是很多人追求的目标，它的意思是，在Oracle数据库中，通过调整性能参数的值，就可以让数据库运转得飞快。 　　实际上这不过是句玩笑，它本身是一句反话，却让很多人误入歧途。我看到很多人，包括一些DBA，凡涉及性能优化，必定谈及性能参数的修改，这实在是一个误区，他把性能参数值的修改对数据库性能的正面影响人为地放大了很多倍，实际上恰恰相反，很多时候修改这些参数产生的却是副作用，原因很简单，Oracle给一个参数一个默认值是让它最大限度地适用于每个数据库，所以它几乎是最优的，当然，绝对有个别数据库需要适当调整，但我认为那是个例，并且，很多时候，修改这些参数的人，他们修改的理由并不是非常充分，不过是想修改一下看看运气而已。 　　本书的内容 　　以下是本书各个章节的内容简介。 　　第1章 引起数据库性能问题的因素 　　这一章主要讨论一些引起数据库性能问题的因素，包含了系统架构、软件代码、数据库设计、存储设计等话题。 　　第2章 锁和阻塞 　　在这一章里，将介绍Oracle数据库中锁的起因及由锁引起的性能问题—阻塞，并将讨论常见的几种阻塞的起因。 　　第3章 Latch和等待 　　这一章讨论Latch，它是Oracle中比锁更轻量级的一种串行机制。热块或是SQL未绑定变量是最常见的导致Latch等待的原因，这一章将对这些成因及解决方法进行论述。 　　第4章 优化器 　　优化器是SQL执行中最核心的部分，如果要分析SQL的性能，就不能不了解Oracle优化器的机制，这一章，我们就带你走进Oracle优化器—CBO的世界。 　　第5章 执行计划 　　当我们分析一条SQL语句的性能时，最先做的事情大概就是分析它的执行计划了。 　　所以，如果连执行计划都看不懂，那SQL调优根本无从谈起。在这一章，我们将讨论CBO（基于成本的优化器）执行计划相关的内容。 　　第6章 Hint 　　Hint指通过人为的方式来约束SQL的执行计划，让它按照我们希望的方式来执行，以达到我们需要的目的—改善性能或者仅仅是试验以对比SQL的执行性能。 　　这一章将讨论Oracle数据库中的大多数Hint。 　　第7章 分析及动态采样 　　对象采样分析是CBO（基于成本的优化器）的灵魂和核心，CBO如果没有了对象的分析数据，就好像一个医生不使用病人的病历来确定病人的病一样危险—那是一种没有依据的、盲目的行为。 　　在这一章里，我们将详细讨论Oracle中和对象分析相关的内容。 　　第8章 并行执行 　　这一章讨论一个和性能关系极大的技术—并行执行。 　　在OLAP（在线分析系统）或者是数据仓库系统中，并行技术使用得非常普遍，在合适的条件下，并行执行将会使SQL的执行效率大幅度提升。 　　第9章 变量绑定 　　这一章将详细讨论一个在性能优化领域经常被谈到的话题—变量绑定。 　　那么，是不是在任何时候变量绑定都是必需的呢？答案是否定的，在这一章中将给出答案。 　　第10章 SQL_TRACE和10046事件 　　SQL_TRACE和10046事件是会话级非常有用的两个工具，它们可以捕获会话当中SQL执行的详细信息，其中10046事件还可以获得SQL绑定变量的信息及发生的等待事件。 　　这一章将详细讨论这两个工具。 　　第11章 10053事件 　　这一章将详细讨论10053事件，它是一个很有用处的工具，当你发现一条SQL总是选择错误的执行计划，而你又百思不得其解的时候，也许你应该去生成一个10053事件的trace文件，看看CBO究竟是如何做出这样的执行计划的。 　　第12章 性能视图和性能参数 　　本章讨论一些Oracle数据库的性能视图和性能参数。 　　性能视图相对于SQL_TRACE来说，可以让我们更直接地获取一些性能数据，帮助我们判断数据库是否出现了性能问题。 　　而性能参数则让我们能够有机会选择一种最适合自己系统的某个参数值，以最大程度地满足当前系统的需要。 　　第13章 性能报告 　　本章介绍了常用的几个性能分析工具及性能报告，包括AWR，STATSPACK和ASH，其中以AWR性能报告作为重点介绍的对象。 　　本章以一个来自于现实生产数据库的AWR报告为题材，来讨论AWR报告的阅读方式，并最终判断出系统的性能所在；STATSPACK介绍了它的安装方法和如何生成报告；ASH也是以一个来自实际生产数据库的性能报告进行性能分析。 　　附录A 常见的等待事件 　　这部分会列出一些常见的等待事件、引起它们的原因及一些内部的机制，可以作为大家在处理性能问题时的一个参考部分。 　　后记 关于数据库的学习方法 　　这一部分是作者对如何学习Oracle的一个心得分享，对于Oracle初学者来说，正确的学习方法非常重要，它可以使你少走很多弯路。 　　如果初学者对于Oracle数据库的学习方法有兴趣，这部分可以作为本书的第一部分来阅读。 　　本书的读者对象 　　1. 本书适合Oracle DBA或者和Oracle相关的开发人员。 　　2. 本书的读者需要有一定的Oracle基础，比如你应该知道什么叫做表，什么叫做索引等。 　　约定 　　1. 本书示例使用的Oracle版本是10gr2。 　　2. 本书自创了一个术语—段对象。 　　这个词大家可能看着有那么一点陌生。作者的意思是，在Oracle数据库中，凡是分配了存储空间的，都称为段，所以段并不一定指的是表，也可能是表的一个分区，还可能是索引、大对象（LOB），或是IOT（索引表），物化视图等。在书中有时候需要描述这些对象时，单独说某个表，或者一个索引，都不能完全概括，所以就统称为段对象。 　　3. 几个未作翻译的术语Extent，Latch和Bind peeking。 　　Extent：我看有些书翻译为“分区”，说实话，在Oracle里面，一提到分区，可能99%以上的人会认为是partition，还有的书翻译为“范围”，这个就更让人匪夷所思，所以在书中这个单词就没有翻译，相信大家也懂。 　　Latch：有的书翻译成“闩”，有的翻译成“锁存”，我总觉得还是不翻译好，只要大家知道它是Oracle里一种类似于锁的保证一些操作串行化的技术就好了。 　　Bind peeking：翻译成“变量窥视”或是“变量窥探”都非常不对头，所以干脆也不翻译。 　　本书的目的 　　笔者从事Oracle DBA的工作已经超过10年，对数据库的理解也一直在改变，就目前来看，我觉得最难的东西不是技术本身，而是什么时候该用什么技术。比如说要使用变量绑定，这非常容易，如果你不会，Google一下，差不多几分钟时间你就会了。可是，这个系统究竟该不该使用变量绑定，我想你Google一天或者一个星期也不一定有答案。原因是每个系统都是独立的，都有自己的业务特点，这需要技术人员根据自己系统的业务特点来度身定做符合自己系统的技术特性。 　　让读者在每一个技术面前先停下来思考一下，这个技术究竟在什么时候应该用，什么时候不应该用，这是笔者写本书的最终目的。 　　致 谢 　　感谢www.itpub.net网站的创始人Tigerfish为本书写序，我一直对他怀有敬意，他在推动中国Oracle数据库的发展 上功不可没。 　　感谢biti（冯春培），eygle（盖国强），kamus（张乐奕）和warehouse（谢永生），他们都是国内顶尖的Oracle专家，感谢他们为本书写的精彩点评。 　　还有来自ITG的Mike，感谢他的热心帮助和鼓励。 　　感谢ITPUB的王蓓小姐（贝贝），在本书的出版过程中，她做了大量的协调工作，才保证这本书的顺利出版。 　　感谢电子工业出版社的张月萍策划和高洪霞编辑，是她们的努力让本书更具可读性和完整性。 　　最后要感谢我的妻子tracy和儿子思墨，是他们让我一直努力工作，最终使本书得以问世。 　　后 记 　　关于数据库的学习方法 　　我想在这里聊一些数据库方面的学习方法，算是对自己这些年学习的一个总结，也可以给那些才进入Oracle领域的朋友们提供一些借鉴。如果能够使你有所收获的话，我将非常高兴。 　　1、英语和技术的关系 　　从2005年开始到现在，我只看过三本关于数据库方面的印刷书籍，都是由一个人写的，他叫Tom Kyte，业内都叫他Tom，这三本书分别是： 　　● 《Expert One-on-One Oracle》—《Oracle专家高级编程》 　　● 《Expert_Oracle_Database_Architecture》—《Oracle 9i&10g;编程艺术深入数据库体系结构 》 　　● 《Effective Oracle by Design》—《Oracle高效设计》 　　在买这三本书时，多少带有些许盲目性，因为崇拜书的作者，所以爱屋及乌地买了他写的所有的书，实际上我用在看这三本书上的时间并不多，更多的时候我都泡在Asktom.Oracle.com这个网站上，就是这个网站，改变了我对问题的思考方式和学习方法。 　　对于大多数中国人来说，特别是做技术的人，英语成为很多人的软肋，这是一个无奈的局面。我甚至听到很多人在说，为什么非要学习英语，自己国家的话说好就行了，言辞之间颇鄙视那些学英语的“崇洋派们”。本身这句话也还不错，作为自己国家的公民，学好自己国家的语言，自然是再好不过的事情。但是很遗憾的是，我们说着自己的语言，却在用着别人的东西。用别人的东西，却拒绝学习别人的语言，这看起来不免有些矛盾。如果有一天世界上所有的商业软件都来自于中国，那么我们再自豪地鄙视那些学习英语的人也不迟。 　　所以我必须要说的是，如果你想把计算机的技术学深一些，请你务必要学好英语，至少要做到能够熟练阅读英文文档的哑巴英语，如果再进一步，你能够使用英语和别人做书面的沟通（比如在论坛中或者E-mail中提出问题），那会更好一些。 　　在Asktom.Oracle.com中有来自世界上很多国家的Oracle DBA或者开发人员在提出问题，我最初的时候只是浏览，后来尝试着用自己蹩脚的英语向Tom提出了一个问题，当收到Tom给出的回复后，当时心情真是无比的激动，可喜之余不免又甚感悲哀，为什么一个简单的提问，却让我欢喜至此呢？原因大概是，我们和他们之间沟通太少了，一个小小的问答，对我来说就像跨过一个巨大的鸿沟。 　　之后的日子里，就慢慢习惯了这种学习方式，当我有一个问题，在找遍了所有的Oracle官方文档，Google和Metalink（一个Oracle公司的在线技术支持平台）未果之后，总是能够在这里得到一个确切的回答，它已经变成了我在技术上最后的依靠了。 　　我们不得不承认和接受一个现实，由于语言的沟壑，使我们学习起这些西方人发明的东西时，比他们自己的人要困难得多，比如对于一个软件，他们已经习惯于随手看一下软件的Manual（联机帮助手册）来了解这个软件的用法，而我们却还在傻傻地等待着软件的汉化或者翻译过来的软件使用教程呢（市面上有很多书都是简单地将某个软件的manual翻译过来，然后出版），这种语言上的障碍使我们和他们在技术上有相当大的差距，这就是我在Asktom.Oracle.com论坛上得到的最切身的感受，我们不仅在技术本身上，而且在一些思维方式上和他们也有明显的不同，这不是妄自菲薄，是我们中国IT从业人员的现状，我们只是封闭在自己的圈子里面做研究，却并不知道外面已经是个什么样子了。 　　我希望大家能够把英语学好（我本人也在努力地学习中），Oracle的官方文档全都是英文的，metalink也全都是英文的，asktom网站也都是英文的，如果我们能够熟练地使用这三个资源，那么我们的技术水平必将上一个新的台阶。 　　2. 如何使用Oracle的官方文档 　　如果你到现在为止，依然没有习惯于使用Oracle的官方文档的话（比如你惧怕英语阅读或者其他的原因），那么你可能要考虑改变一下你的学习方式了，因为Oracle官方文档是Oracle公司提供的最权威的技术资料，它基本上包含了Oracle所有的技术，你在这里可以找到大多数你想找的东西。 　　也许那些看起来无比长的英文文档让你望而却步，至少我最初也是如此的。但是随着自己尝试着去阅读了几篇之后，感觉情况并没有想象中的那么坏，我居然读懂了一大半。因此建议大家也要树立信心，要鼓起勇气来阅读英文文档，当你经常阅读时，你会发现其实它并没有你想的那么难，你使用它的次数也多，你就越能接受和使用它。 　　这里简要地介绍几个使用频率比较高的官方文档，希望大家能够经常使用它们： 　　《New Features Guide》 　　一般称为新特性，当我们要使用一个新版本数据库的时候，我们应该先阅读这篇文档。可以通过目录来浏览自己感兴趣的部分。这篇文档主要介绍的就是当前这个版本的数据库较从前的版本有了哪些新的技术，这篇文档可以帮助你快速地了解一个新版本数据库的新特性，这比阅读那些具体的文档要省力得多。 　　《Concepts》 　　当我们需要了解一个概念或者技术的具体含义或机制时，我们需要参考这篇文档，这里面基本上包含了所有Oracle相关的概念和技术。 　　比如什么是表，什么是索引，什么是段等。 　　或者什么是SGA，PGA等。 　　或者什么是并发，事务等。 　　这是Oracle最重要的一篇文档，希望大家能够经常使用它。 　　《Reference》 　　这里面主要包含了四部分内容： 　　●初始化参数 　　●视图 　　●等待事件 　　●统计信息 　　这是我使用频率最高的文档之一，基本上每天都要打开几次，主要是查询一些视图及其字段的解释及等待事件的解释，初始化参数的解释也会经常用到它，另外它还包含了一些统计项目，比如v$sesstat中的统计项目的解释就可以从这篇文档中找到。 　　《SQL Reference》 　　这篇文档大家应该再熟悉不过了，当你记不住某条SQL的命令或者搞不清楚某条SQL的选项时，就需要从这篇文档中获取答案，它包含了Oracle所有的SQL语法。 　　《Administrator's Guide》 　　这可以看做一本Oracle的实战手册，很多Oracle的技术和特性在这篇文档里都能够找到相应的示例，所以建议大家也经常使用它。 　　《PL/SQL Packages and Types Reference》 　　如果你是一个喜欢使用Oracle提供的PL/SQL包工作的人，这篇文档你就应该经常使用到，它包含了Oracle提供的所有PL/SQL包，比如我们经常使用到的DBMS_STATS，它是用来做分析用的包，包里面每个存储过程及参数在这篇文档中都有详细的说明。 　　《Performance Tuning Guide》 　　如果你要学习Oracle数据库性能优化的话，这篇文档应该要好好读几遍，这里面包含了所有和性能优化相关的技术和方法。 　　3、学会思考 　　我们不能机械地去学一些技术，那样只能让自己陷入一个由自己打造的万劫不复的技术深渊，无法自拔，因为技术是无止境的，而人的精力是有限的，这样只能使自己整天生活在一种压抑和苦闷当中。 　　我们要学会在技术面前理性的思考，比如对于一个新技术，流复制（Streams Replication），当我看到这个概念的时候，我告诉自己，这不过又是Oracle为用户提供的另外一种数据同步的机制而已，如果我们有这方面的需求，我会带着我们的需求去看相关的文档，以便确定这种技术是否适合我们的系统，否则，我可能只是做一些粗浅的了解，仅此而已，切勿把自己陷入到技术的泥潭当中去。 　　有目的地学习技术，做到学以致用，你就会过得很快乐，相反，你就会非常痛苦，尽管你每天都在学习，可是你是否想过，你一个人学习，Oracle却有成千上万的开发人员在开发新版本的数据库和新的技术，你能学完吗？ 　　理性地学习，心平气和地学习，是做技术的人的一种生活态度，希望本书对大家在学习技术上会有所帮助。 　　 序言 　　性能优化是数据库应用的核心问题。目前的商业或开源的数据库产品，发展已日臻成熟，很少有经常发生崩溃急需修复的情形。故DBA除了日常的常规维护任务外，大多把精力花在优化数据库上。在2005年的时候，ITPUB也曾出过一本《Oracle数据库性能优化》（盖国强、冯春培、叶梁、冯大辉主编）的技术书，颇受Oracle DBA们的欢迎。现在很高兴地看到在ITPUB技术丛书里又增加了一本关于数据库优化知识的书籍。 　　ITPUB于2001年9月26日成立的，已发展为国内最大的数据库技术讨论社区。本书作者谭怀远先生则是在2001年9月28日加入了ITPUB，相交至今将近九年时间。他在这么长久的时间，长期工作在数据库业务的第一线，积累了大量丰富的经验，也形成自己独到的见解。而这些见解，又大部分体现在本书的文字里，本书既是知识的归纳总结，同时又是个人技术感情（恕我在这里使用了一个创新的词汇，大多数长期从事技术工作的人，都有一种有墨在胸，不得不发的感觉）的抒发。纵观全书，我个人对作者所说的“最难的东西不是技术本身，而是什么时候该用什么技术”深表认同。当DBA从烦琐的日常工作脱身出来，举目远望的时候，再往前的一片田野便是架构问题，最好的最彻底的，能一劳永逸的优化，往往从架构设计开始。期待怀远君将来的新作，可以在这片更广阔的天地里驰骋。 　　我感到本书最大的一个特点在于，作者通过自己的一种情绪化的东西在写作，也可以说是对于技术的一种感情告白，所以是真挚的，这种真挚将影响到读者阅读时的情绪，让你在一种颇为感性化和人性化的氛围里阅读，轻松而又有趣，而不是冷冰冰的枯燥的技术讨论，这是本书区别于其他技术类书籍的一个显著特点。 　　本书里，涵盖了几乎所有优化相关的知识点，以及一些很新的内容，比如bind peeking、并行执行、执行计划、Cardinality（基数）、10053事件等，这些内容对于那些渴望深度了解性能优化的读者来说，是非常有用的。 　　ITPUB前身是在smiling上的Oracle电子小组，刚刚开始的时候ITPUB的板块不多，只有Oracle数据库管理、Oracle开发、OCP、Cisco、网络集成、海阔天空这几个板块，会员数只有一万多人，今年过9年的发展，ITPUB已拥有技术板块100多个，注册会员数量超过230万人。每天更新的讨论帖数以万计。ITPUB的发展与像怀远君这样的专家、第一线技术工作者的长期支持是分不开的，在此也向怀远君表示感谢，没有你们就不会有今天的ITPUB。 　　ITPUB创始人 tigerfish 　　2010年6月8日 　　 媒体评论 　　很多年前就在itpub看到作者的身影，也了解到作者管理着大量的数据库。多年的不断锤炼让作者在Oracle数据库领域有了丰富的经验。在数据库优化领域，国内的书籍相对比较少，不论哪种数据库，比较多的都是类似工具手册一样。写书是一件很不容易的事情，对作者的知识体系有着极高的要求，所以市面上流传的很多都是简单地将英文的文档翻译为中文的手册类的书籍。作者将自己多年的经验用自己的语言和通俗的比喻给我们展示出来，带给人的是另一种体验，更亲切和容易理解。除了常规的优化所涉及的范畴及Oracle 10g开始推出的AWR和ASH之外，作者还引出了10053这样的CBO相关的事件及不少的Hint方法，这些都将帮助我们非常深入地研究数据库的 SQL优化问题。相信作者将亲身经历的体验深入浅出地展示给我们，能给Oracle数据库爱好者很好的帮助。 　　——冯春培（biti） 　　 　　当我们在2004年开始编辑出版Oracle技术书籍时，国内原创的作品还十分有限，现在，这种情况完全改变了，越来越多的技术爱好者开始总结、写作和分享，Oracle技术出版物开始丰富起来。在这个历程中，ITPUB论坛一直推动着Oracle数据库技术的探讨和应用，作者alantany正是来自于ITPUB的一位技术专家，他将自己多年的实践与经验不断总结出来，和我们大家分享，这种精神与坚持值得我们尊敬，我乐于见到这样的作品问世，也期待作者能够坚持不懈，不断同我们分享他的知识与经验。 　　——盖国强（eygle）恩墨科技创始人，Oracle ACE总监 　　 　　很欣喜地看到这几年来国内Oracle数据库技术原创书籍的蓬勃发展，对每一位能够坐下来并且将自己的经验写出来的作者我都报以深深的敬意。对于Oracle数据库而言，也许在现在随着安装的日渐简易和默认性能的不断优化，一份默认的数据库安装，甚至是保证数据库可以正常运行都不再需要太多的专业知识，然而数据库优化仍然是非常专业的部分，这需要多年的实际工作经验积累。 可以说这本书的作者拥有得天独厚的工作环境，据我所知，他所参与管理的数据库无论是数量还是大小还是性能要求上在国内都可以排入前列，因此这是一本融合了真知灼见、可以指导实际工作的Oracle数据库性能优化书籍。 实际上我更希望读者们可以从后记开始读起，作者在后记中提及的所有观点都与我不谋而合，我同样相信无论是后记中这些观点还是全书中记录的技术知识，对于所有从业人员都有极大帮助。 　　——业内资深Oracle技术专家，Oracle ACE张乐奕（Kamus） 　　 　　据我所知作者是中国独立撰写Oracle性能优化书籍的第一人，该书几乎涵概了Oracle性能优化的所有主题，在国内数据库性能优化领域的书籍中实属罕见。 　　——谢永生（warehouse) 资深Oracle培训讲师 　　 　　The fast and easy way to understanding the fundamentals of database performance tunning. If you’re tired of wading through huge technical manuals that drown you in jargon, making it difficult to decipher database performance issues, help has finally arrived. Simple enough for a beginner, but challenging enough for an advanced user, this book is your shortcut to mastering database perfperformance tunning. 　　本书提供了一种理解Oracle性能优化的简单快捷的方法。如果你已经被成堆的关于性能优化的技术手册淹没，身心疲惫，无从下手，那么，这本书将帮你走出困境。无论你是初学者，或是经验丰富的技术人员，你都将从这本书中获得一个掌握数据库性能优化的捷径。 　　——Mike ITG (Investment technology group) 资深软件工程师 　　
Oracle Database 9i10g11g编程艺术：深入数据库体系结构（第2版）--详细书签版
CruiseYoung提供的带有详细书签的电子书籍目录 http://blog.csdn.net/fksec/article/details/7888251 Oracle Database 9i/10g/11g编程艺术:深入数据库体系结构:第2版(世界顶级专家Thomas Kyte力作) 基本信息 原书名： Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions, Second Edition [ 原出版社： Apress 作者： (美)Thomas Kyte 译者： 苏金国 王小振 丛书名： 图灵程序设计丛书 数据库 出版社：人民邮电出版社 ISBN：9787115244857 上架时间：2011-1-5 出版日期：2011 年1月 开本：16开 页码：706 版次：2-1 编辑推荐 　　久负盛名的Oracle经典 　　 世界顶级专家Thomas Kyte力作 　　 Ask Tom！解决你所有的Oracle疑难杂症 内容简介 　　本书是一本关于oracle database 9i、10g 和11g 数据库体系结构的权威图书，涵盖了所有重要的oracle 体系结构特性，包括文件、内存结构和进程，锁和闩，事务、并发和多版本，表和索引，数据类型，分区和并行，以及数据加密等，并利用具体的例子来全面介绍每个特性，不仅讨论了各个特性是什么，还说明了它是如何工作的，如何使用这个特性来开发软件，以及有关的常见陷阱。 　　 本书面向所有oracle 数据库应用开发人员和dba。 作译者 作者 　　Thomas Kyte Oracle公司核心技术集团副总裁。从5.1.1c版本开始使用Oracle，自7.0.9版本发布就一直任职于Oracle公司，帮助Oracle数据库用户设计和构建系统，或者对系统进行重构和调优。此前曾是一位系统集成师，主要为美国军方和政府部门的客户构建大规模的异构数据库和应用。长期主持Oracle Magazine “Ask Tom”专栏，热心回答困扰全世界Oracle开发人员和DBA的各种问题。除本书外，还著有广受好评的《Oracle专家高级编程》和《Oracle高效设计》。 作者: Thomas Kyte 　　Thomas Kyte是Oracle公司核心技术集团的副总裁，从Oracle 7.0.9版本开始就一直任职于Oracle公司，不过，其实他从5.1.5c版本就开始使用Oracle了。 在Oracle公司，Kyte专门负责Oracle数据库，他的任务是帮助使用Oracle数据库的客户，并与他们共同设计和构建系统，或者对系统进行重构和调优。在进入Oracle公司之前，Kyte是一名系统集成人员，主要为美国军方和政府部门的客户构建大规模、异构数据库。 Thomas Kyte就是主持Oracle Magazine Ask Tom专栏和Oracle公司同名在线论坛的那个Tom，他通过这一方式热心地回答困扰着Oracle开发人员和DBA的各种问题。 目录 封面 -40 版权声明 -38 译者序 -37 序 -36 第1版序 -34 前言 -31 致谢 -24 配置环境 -23 目录 -5 第1章 开发成功的Oracle应用 1 1.1 我的方法 2 1.2 黑盒方法 3 1.3 开发数据库应用的正确（和不正确）方法 10 1.3.1 了解Oracle体系结构 11 1.3.2 理解并发控制 19 1.3.3 多版本控制 22 1.3.4 数据库独立性 28 1.3.5 怎么能让应用运行得更快 42 1.3.6 DBA与开发人员的关系 44 1.4 小结 45 第2章 体系结构概述 46 2.1 定义数据库和实例 47 2.2 SGA和后台进程 52 2.3 连接Oracle 54 2.3.1 专用服务器 54 2.3.2 共享服务器 56 2.3.3 TCP/IP连接的基本原理 57 2.4 小结 59 第3章 文件 60 3.1 参数文件 61 3.1.1 什么是参数 62 3.1.2 遗留的init.ORA参数文件 65 3.1.3 服务器参数文件 67 3.1.4 参数文件小结 72 3.2 跟踪文件 73 3.2.1 请求的跟踪文件 74 3.2.2 针对内部错误生成的跟踪文件 78 3.2.3 跟踪文件小结 82 3.3 警告文件 83 3.4 数据文件 85 3.4.1 简要回顾文件系统机制 86 3.4.2 Oracle数据库中的存储层次体系 87 3.4.3 字典管理和本地管理的表空间 90 3.5 临时文件 92 3.6 控制文件 94 3.7 重做日志文件 94 3.7.1 在线重做日志 95 3.7.2 归档重做日志 97 3.8 密码文件 99 3.9 修改跟踪文件 102 3.10 闪回日志 103 3.10.1 闪回数据库 103 3.10.2 闪回恢复区 104 3.11 DMP文件（EXP/IMP文件） 104 3.12 数据泵文件 105 3.13 平面文件 108 3.14 小结 109 第4章 内存结构 110 4.1 进程全局区和用户全局区 110 4.1.1 手动PGA内存管理 111 4.1.2 自动PGA内存管理 117 4.1.3 手动和自动内存管理的选择 127 4.1.4 PGA和UGA小结 129 4.2 系统全局区 129 4.2.1 固定SGA 133 4.2.2 重做缓冲区 134 4.2.3 块缓冲区缓存 135 4.2.4 共享池 141 4.2.5 大池 143 4.2.6 JAVA池 144 4.2.7 流池 145 4.2.8 自动SGA内存管理 145 4.2.9 自动内存管理 147 4.3 小结 148 第5章 Oracle进程 149 5.1 服务器进程 149 5.1.1 专用服务器连接 150 5.1.2 共享服务器连接 152 5.1.3 数据库常驻连接池 152 5.1.4 连接与会话 153 5.1.5 专用服务器与共享服务器 158 5.1.6 专用/共享服务器小结 161 5.2 后台进程 162 5.2.1 中心后台进程 163 5.2.2 工具后台进程 171 5.3 从属进程 173 5.3.1 I/O从属进程 173 5.3.2 Pnnn：并行查询执行服务器 174 5.4 小结 175 第6章 锁和闩 176 6.1 什么是锁 176 6.2 锁定问题 179 6.2.1 丢失更新 179 6.2.2 悲观锁定 180 6.2.3 乐观锁定 182 6.2.4 乐观锁定还是悲观锁定 188 6.2.5 阻塞 188 6.2.6 死锁 191 6.2.7 锁升级 195 6.3 锁类型 195 6.3.1 DML锁 196 6.3.2 DDL锁 204 6.3.3 闩 209 6.3.4 手动锁定和用户定义锁 217 6.4 小结 218 第7章 并发与多版本控制 219 7.1 什么是并发控制 219 7.2 事务隔离级别 220 7.2.1 READ UNCOMMITTED 221 7.2.2 READ COMMITTED 223 7.2.3 REPEATABLE READ 224 7.2.4 SERIALIZABLE 226 7.2.5 READ ONLY 228 7.3 多版本控制读一致性的含义 229 7.3.1 一种会失败的常用数据仓库技术 229 7.3.2 解释热表上超出期望的I/O 230 7.4 写一致性 233 7.4.1 一致读和当前读 233 7.4.2 查看重启动 235 7.4.3 为什么重启动对我们很重要 238 7.5 小结 239 第8章 事务 240 8.1 事务控制语句 240 8.2 原子性 242 8.2.1 语句级原子性 242 8.2.2 过程级原子性 244 8.2.3 事务级原子性 247 8.2.4 DDL与原子性 247 8.3 持久性 247 8.3.1 COMMIT的WRITE扩展 248 8.3.2 非分布式PL/SQL代码块中的COMMIT 249 8.4 完整性约束和事务 250 8.4.1 IMMEDIATE约束 251 8.4.2 DEFERRABLE约束和级联更新 251 8.5 不好的事务习惯 255 8.5.1 在循环中提交 255 8.5.2 使用自动提交 261 8.6 分布式事务 261 8.7 自治事务 263 8.7.1 自治事务如何工作 264 8.7.2 何时使用自治事务 265 8.8 小结 268 第9章 redo与undo 269 9.1 什么是redo 269 9.2 什么是undo 270 9.3 redo和undo如何协作 273 9.4 提交和回滚处理 277 9.4.1 COMMIT做什么 277 9.4.2 ROLLBACK做什么 283 9.5 分析redo 284 9.5.1 测量redo 284 9.5.2 能关掉重做日志生成程序吗 286 9.5.3 为什么不能分配一个新日志 289 9.5.4 块清除 291 9.5.5 日志竞争 294 9.5.6 临时表和redo/undo 296 9.6 分析undo 299 9.6.1 什么操作会生成最多和最少的undo 299 9.6.2 ORA-01555: snapshot too old 错误 301 9.7 小结 310 第10章 数据库表 311 10.1 表类型 311 10.2 术语 313 10.2.1 段 313 10.2.2 段空间管理 315 10.2.3 高水位线 316 10.2.4 FREELIST 317 10.2.5 PCTFREE和PCTUSED 320 10.2.6 LOGGING和NOLOGGING 323 10.2.7 INITRANS和MAXTRANS 324 10.3 堆组织表 324 10.4 索引组织表 327 10.5 索引聚簇表 340 10.6 散列聚簇表 347 10.7 有序散列聚簇表 355 10.8 嵌套表 357 10.8.1 嵌套表语法 358 10.8.2 嵌套表存储 364 10.8.3 嵌套表小结 367 10.9 临时表 368 10.10 对象表 374 10.11 小结 380 第11章 索引 382 11.1 Oracle索引概述 382 11.2 B*树索引 384 11.2.1 索引键压缩 386 11.2.2 反向键索引 389 11.2.3 降序索引 -1 11.2.4 什么情况下应该使用B*树索引 396 11.2.5 B*树小结 405 11.3 位图索引 406 11.3.1 什么情况下应该使用位图索引 407 11.3.2 位图联结索引 410 11.3.3 位图索引小结 413 11.4 基于函数的索引 413 11.4.1 重要的实现细节 413 11.4.2 一个简单的基于函数的索引例子 414 11.4.3 只对部分行建立索引 422 11.4.4 实现有选择的唯一性 424 11.4.5 关于ORA-01743的警告 424 11.4.6 基于函数的索引小结 425 11.5 应用域索引 -1 11.6 关于索引的常见问题和神话 426 11.6.1 视图能使用索引吗 427 11.6.2 Null和索引能协作吗 427 11.6.3 外键是否应该加索引 429 11.6.4 为什么没有使用我的索引 430 11.6.5 神话：索引中从不重用空间 435 11.6.6 神话：最有差别的元素应该在最前面 438 11.7 小结 441 第12章 数据类型 442 12.1 Oracle数据类型概述 442 12.2 字符和二进制串类型 444 12.2.1 NLS概述 445 12.2.2 字符串 448 12.3 二进制串：RAW类型 453 12.4 数值类型 455 12.4.1 NUMBEI类型的语法和用法 457 12.4.2 BINARY_FLOAT/BINARY_DOUBLE类型的语法和用法 460 12.4.3 非固有数值类型 461 12.4.4 性能考虑 461 12.5 LONG类型 463 12.5.1 LONG和LONG RAW类型的限制 463 12.5.2 处理遗留的LONG类型 464 12.6 DATE、TIMESTAMP和INTERVAL类型 469 12.6.1 格式 469 12.6.2 DATE类型 470 12.6.3 TIMESTAMP类型 475 12.6.4 INTERCAL类型 482 12.7 LOB类型 484 12.7.1 内部LOB -1 12.7.2 BFILE 495 12.8 ROWID/UROWID类型 497 12.9 小结 497 第13章 分区 499 13.1 分区概述 499 13.1.1 提高可用性 500 13.1.2 减少管理负担 502 13.1.3 改善语句性能 505 13.2 表分区机制 507 13.2.1 区间分区 508 13.2.2 散列分区 510 13.2.3 列表分区 513 13.2.4 间隔分区 515 13.2.5 引用分区 520 13.2.6 组合分区 524 13.2.7 行移动 526 13.2.8 表分区机制小结 528 13.3 索引分区 529 13.3.1 局部索引与全局索引 530 13.3.2 局部索引 530 13.3.3 全局索引 535 13.4 再论分区和性能 547 13.5 审计和段空间压缩 552 13.6 小结 553 第14章 并行执行 555 14.1 何时使用并行执行 556 14.2 Oracle Exadata 558 14.3 并行查询 558 14.4 并行DML 564 14.5 并行DDL 566 14.5.1 并行DDL和使用外部表的数据加载 567 14.5.2 并行DDL和区段截断 568 14.6 并行恢复 576 14.7 过程并行化 577 14.7.1 并行管道函数 578 14.7.2 DIY并行化 580 14.7.3 老式DIY并行化 583 14.8 小结 587 第15章 数据加载和卸载 588 15.1 SQLLDR 588 15.1.1 用SQLLDR加载数据的常见问题 592 15.1.2 SQLLDR警告 613 15.1.3 SQLLDR小结 614 15.2 外部表 614 15.2.1 建立外部表 615 15.2.2 处理错误 619 15.2.3 使用外部表加载不同的文件 622 15.2.4 多用户问题 623 15.2.5 外部表小结 624 15.3 平面文件卸载 624 15.4 数据泵卸载 631 15.5 小结 633 第16章 数据加密 634 16.1 加密类型 634 16.1.1 动态数据 634 16.1.2 静态数据 635 16.1.3 手动应用加密 638 16.1.4 Oracle钱夹 639 16.1.5 透明列级加密 641 16.1.6 透明表空间加密 644 16.2 加密不是访问控制 646 16.3 实现手动应用加密 647 16.3.1 避免使用手动方法的原因 648 16.3.2 手动方法的性能影响 648 16.3.3 何时使用手动方法 652 16.4 实现列级加密 652 16.4.1 如何使用列级加密 653 16.4.2 列级加密的数据存储 653 16.4.3 测量列级加密的性能影响 657 16.4.4 影响大小 657 16.4.5 列级加密的限制 662 16.5 实现表空间加密 663 16.5.1 如何使用表空间加密 663 16.5.2 表空间加密的数据存储 664 16.5.3 测量表空间加密的性能影响 665 16.6 决定采用哪种加密技术 670 16.7 小结 671 索引 672 译者序 　　Oracle Database 11g的推出让关注Oracle的人欣喜万分，不过也不免有些担心，因为此前还没有合适的书系统而深入地介绍这个新版本。要想学习和掌握它的诸多新特性，只能从Oracle手册入手，而数万页的11g手册不免让人心存畏惧，从中挑出对新特性的描述更需要一双“火眼金睛”。 　　好消息！在本书第1版出版时隔4年后，Thomas Kyte及时了解了大家的这一迫切需求，根据他的实战经验以及人们最关心的问题对这本书做了全面补充和调整，以涵盖11g最受关注的多项特性。例如11g引入dbms_parallel_execute包来帮助自动实现原来需要人工实现的并行化，以及引入PSQ来控制并行度，限制资源的过度使用，从而进一步改进并行化的实现。11g还增加了对递归调用子查询的支持，来避免原先令人费解的connect by语法。另外通过闪回数据归档支持长期闪回查询，这意味着查询几个月前甚至几年前的数据不再是奇谈。延迟段创建特性的引入更让我们看到了Oracle对于性能的“锱珠必较”和精益求精。所有这些内容都在这一版中得以体现，Tom还专门增加了一章来讨论Oracle中的数据加密。相信你的问题都能在这一版中得到解答。 　　这一版仍沿袭了上一版的叙事风格，Tom通过轻松交流的方式，让你从具体的例子、具体的实践中了解技术细节，在知道“怎样做”的同时还能理解“为什么这样做”。还特别根据读者对上一版内容的反馈，在文中追加了大量注解，另外还利用注解强调了11g与9i/10g的区别。相信你已经迫不及待地想要翻开下一页了，那么，进入Tom的Oracle世界吧！ 　　很高兴上一版出版后得到了读者的青睐，能够让更多中国读者领略Tom的这一力作，这让我们也倍感自豪。对于第2版的翻译，我们同样不敢马虎，尽量减少歧义，希望能让读者更轻松地阅读和理解。不过由于水平有限，译文肯定有不当之处，敬请批评指正。 　　 　　 前言 　　过去我一直在开发Oracle软件，并与其他Oracle开发人员一同工作，帮助他们构建可靠、健壮的基于Oracle数据库应用程序。在这个过程中积累了一些经验，正是这些经验赋予我灵感，才有了本书中的内容。这本书实际上反映了我每天做了些什么，汇集了我所看到的人们每天遇到的问题。 　　本书涵盖了我认为最重要的一些内容，即Oracle数据库及其体系结构。我也可以写一本书名类似的其他方面的书，向你解释如何用一种特定的语言和体系结构开发应用程序。例如，我可以告诉你如何使用JSP（JavaServer Pages）与EJB（Enterprise JavaBeans）通信，EJB又如何使用JDBC与Oracle通信。不过，归根结底，最后还是要了解Oracle数据库及其体系结构（本书介绍的内容），才能成功地构建这样一个应用程序。要想成功地使用Oracle进行开发，我认为有些内容你必须了解，而不论你是一位使用ODBC的Visual Basic程序员、使用EJB和JDBC的Java程序员，还是使用DBI Perl的Perl程序员，这本书都会介绍这些通用的知识。本书并不推崇哪一种特定的应用体系结构，在此没有比较三层结构和客户/服务器结构孰优孰劣。我们只是讨论数据库能做什么，另外关于数据库如何工作，我们还会指出你必须了解哪些内容。由于数据库是所有应用体系结构的核心，所以这本书适用面很广。 　　顾名思义，本书的重点是数据库体系结构，并强调数据库本身如何工作。我会深入地分析Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库和实例的进程。然后讨论一些重要的数据库主题，如锁定、并发控制、事务、redo和undo，还会解释为什么了解这些内容很重要。最后，我们再来分析数据库中的物理结构，如表、索引和数据类型，并介绍哪些技术能最优地使用这些物理结构。 　　本书内容 　　如果开发的选择余地很大，则会带来一些问题，其中一个问题是有时很难确定哪种选择最能满足特定需求。每个人都希望灵活性尽可能大（有尽可能多的选择），同时又希望能简单明了，换句话说，希望尽量容易。Oracle为开发人员提供的选择几乎无穷无尽。没有人会说“这在Oracle中做不到”，而只会说“在Oracle中你想用多少种不同的方法来实现”。希望这本书能帮你作出正确的选择。 　　如果你不只是想知道做何选择，还想了解有关Oracle特性和功能的一些原则和实现细节，这本书就很适合你。例如，Oracle有一个很棒的特性，称为并行执行（parallel execution）。Oracle文档会告诉你如何使用这个特性，并说明它到底能做什么。不过，Oracle文档没有告诉你应该在什么时候用这个特性，更重要的是没有指出什么时候不该使用这个特性。另外，文档一般没有提供特性的实现细节，如果你不清楚，可能会因此而困扰（我指的不是bug，而是说你可能很想知道这个特性如何工作，以及为此是怎样具体设计的，但从文档中找不到答案）。 　　在本书中，我不仅会尽力阐明各个特性如何工作，还会指出什么情况下要考虑使用某个特性或实现，并解释为什么。我认为，理解“怎么做”固然很重要，但理解“什么时候做”和“为什么这样做”（以及“什么时候不做”和“为什么不做”）也同样重要！ 　　读者对象 　　本书面向那些使用Oracle作为数据库后端开发应用程序的人员。专业Oracle开发人员如果想了解如何在数据库中完成某些工作，同样可以参考本书。本书相当实用，所以DBA也会对书中的许多内容感兴趣。书中大部分例子都使用SQL*Plus来展示关键特性，所以如果想通过本书来了解如何开发一个很酷的GUI，可能不能如愿。不过，从这本书中，你将知道Oracle数据库如何工作，它的关键特性能做些什么，以及什么时候应该（和不应该）使用这些特性。 　　如果你想事半功倍地使用Oracle，如果你想了解使用现有特性的新方法，如果你想知道这些特性在真实世界中如何应用（不只是展示如何使用特性，而是首先分析为什么要用这个特性），就请阅读本书。作为技术经理，如果你手下的开发人员在开发Oracle项目，你可能也会对本书感兴趣。从某种程度上讲，技术经理也要懂数据库，而且要知道这对于成功至关重要。如果技术经理想安排员工进行适当的技术培训，或者想确保员工了解他们应该掌握的技术，就可以利用本书来“充电”。 　　要想更好地学习本书的内容，要求具备以下能力。 　　了解SQL。不要求你能编写最棒的SQL代码，但是如果用过SQL，对SQL有实战经验，这会很有帮助。 　　掌握PL/SQL。这不是一个必要的前提，但是有助于你“领会”书中的例子。例如，本书不会教你怎样编写一个FOR循环，或者如何声明一个记录类型，这些内容可以参考Oracle文档和许多相关的图书。不过，这并不是说你从本书中学不到PL/SQL的知识。不是这样的。通过阅读本书，你会对PL/SQL的许多特性相当熟悉，而且会学到一些新方法，还会注意到你以前以为不存在的一些包和特性。 　　接触过某种第三代语言（third-generation language，3GL），如C或Java。我相信，如果你能阅读3GL语言编写的代码，或者编写过这种代码，肯定能顺利地阅读和理解本书中的例子。 　　熟悉Oracle Concepts手册。 　　最后再说两句，由于Oracle文档实在太庞大了，这让很多人都有些畏惧。如果你刚开始读Oracle Concepts手册，或者还没有看过，那我可以告诉你，这个手册绝对是一个很好的起点。它大约有400页（我知道页数是因为我编写了一部分，并且编辑了每一页），涉及你需要知道的许多重要的Oracle概念。其中不会涵盖每一个技术细节（Oracle文档提供了技术细节，不过它有10 000页到20 000页之多），但你能从中学到所有重要的概念。这个手册涉及以下主题（这里所列的并不完整）： 　　数据库中的结构，数据如何组织和存储； 　　分布式处理； 　　Oracle的内存体系结构； 　　Oracle的进程体系结构； .　　你要使用的模式对象（表、索引、聚簇等）； 　　内置数据类型和用户定义的数据类型； 　　SQL存储过程； 　　事务如何工作； 　　优化器； 　　数据完整性； 　　并发控制。 　　我自己也会时不时地温习这些内容。这些都是基础，如果不了解这些知识，创建的Oracle应用程序就很容易失败。建议通读Oracle Concepts手册来了解这些主题。 　　本书组织结构 　　为了帮助你更好地使用本书，大部分章都分为4个部分（见稍后的内容）。这个划分并不严格，不过有助于你快速地找到感兴趣的方面，从中获得所需的更多信息。本书有16章，每一章都像一本“迷你书”，可以单独成册。有时我会引用其他章中的例子或特性，不过你完全可以从书中任选一章，不参考其他章也能顺利阅读。例如，要理解或使用第14章关于并行机制的知识，就不必先阅读介绍数据库表的第10章。 　　许多章的格式和风格基本上都一样。 　　首先是特性或功能的介绍。 　　说明为什么想使用（或者不想使用）这个特性或功能。我会概述哪些情况下要考虑使用这个特性，而哪些情况下不考虑。 　　如何使用这个特性。这里提供的信息不是完全照搬SQL参考资料中的内容，而是会以一种循序渐进的方式组织。我会清楚地指出哪些是你需要的，哪些是你必须做的，另外哪些环节需要仔细检查。这一部分包括以下内容： 　　如何实现这个特性； 　　许许多多的例子； 　　如何调试这个特性； 　　使用这个特性的忠告； 　　如何（主动地）处理错误。 　　对上述内容的小结。 　　书中有相当多的例子和大量的代码，这些都可以从http://www.apress.com 的Source Code区下载。下面将详细介绍每一章的内容。 　　第1章：开发成功的Oracle应用 　　从这一章开始，我将介绍数据库编程的基本方法。所有数据库创建得并不一样，要想按时、成功地开发数据库驱动的应用，你必须了解你的数据库能做什么，是怎么做的。如果不清楚数据库能做什么，就很可能不断地遭遇“闭门造车”的窘境，徒劳地从头开发数据库本已提供的功能；如果不清楚数据库是怎么工作的，很可能开发出性能很差的应用，达不到预期的要求。 　　这一章先根据经验分析了一些应用，这些应用都因为缺乏对数据库的基本理解而导致项目失败。这一章就采用这种“拿例子说话”的方式，讨论了开发人员必须了解数据库的哪些基本特性和功能。关键是，不要把数据库当成一个黑盒，不要认为它能自己努力得出答案并自行负责可扩展性和性能。 　　第2章：体系结构概述 　　这一章介绍Oracle体系结构的基础知识。首先给出两个术语的明确定义——“实例”（instance）和“数据库”（database），Oracle领域的许多人都对这两个词存在误解。我们还会简要介绍系统全局区（System Global Area，SGA）和Oracle实例底层的进程，并分析“连接Oracle”这样一个简单的动作是如何实现的。 　　第3章：文件 　　这一章将深入介绍构成Oracle 数据库和实例的8类文件，从简单的参数文件到数据文件和重做日志文件（redo log file）都会涵盖它们。我们将说明这些文件是什么，为什么有这些文件，以及如何使用它们。 　　第4章：内存结构 　　这一章讨论Oracle如何使用内存，包括各个进程中的内存（PGA内存，PGA即进程全局区）和共享内存（SGA）。我们会分析手动和自动PGA内存管理之间的区别，并介绍Oracle Database 10g中的SGA内存管理，还会说明各种方法适用于什么情况。读完这一章之后，你会对Oracle如何使用和管理内存有深入的了解。 　　第5章：Oracle进程 　　这一章概述了各种Oracle进程（服务器进程和后台进程），另外还相当深入地讨论了通过共享服务器进程或专用服务器进程连接数据库有何区别。启动Oracle实例时会看到一些后台进程，这一章将逐一介绍其中一些重要的后台进程（如LGWR、DBWR、PMON和SMON），并分别讨论这些进程的功能。 　　第6章：锁和闩 　　不同的数据库有不同的行事方法（SQL Server里能做的在Oracle中不一定能做）。应当了解Oracle如何实现锁定和并发控制，这对于应用的成功至关重要。这一章将讨论Oracle解决这些问题的基本方法，可以应用哪些类型的锁[DML、DDL和闩（latch）]，还会指出如果锁定实现不当，会出现哪些问题（死锁、阻塞和锁升级）。 　　第7章：并发与多版本控制 　　这一章介绍我最喜欢的Oracle特性——多版本控制（multi-versioning），并讨论它对并发控制和应用设计有什么影响。在这里能清楚地看到，所有数据库创建得都不一样，具体的实现会对应用的设计产生影响。我们先回顾ANSI SQL标准定义的各个事务隔离级别，并介绍它们在Oracle中的具体实现（还会介绍其他数据库中的实现）。基于多版本特性，Oracle能够在数据库中提供非阻塞读（non-blocking read），本章接下来会分析多版本特性对我们有什么影响。 　　第8章：事务 　　事务是所有数据库的一个基本特性，这也是数据库区别于文件系统的一个方面。不过，事务常常遭到误解，很多开发人员甚至不知道他们有时没有使用事务。这一章将讨论Oracle中应当如何使用事务，还列出了使用其他数据库进行开发时可能出现的一些“坏习惯”。具体而言，我们将讨论原子性的含义，并说明原子性对Oracle中的语句有何影响。这一章还会讨论事务控制语句（COMMIT、SAVEPOINT和ROLLBACK）、完整性约束和分布式事务（两段提交或2PC），最后介绍自治事务。 　　第9章：redo与undo 　　可能有人说，开发人员不用像DBA那样深入地了解redo（重做信息）和undo（撤销信息）的细节，但是开发人员确实要清楚redo和undo在数据库中所起的重要作用。这一章首先对redo下一个定义，然后分析COMMIT到底做什么，并讨论怎么知道生成了多少次redo，如何使用NOLOGGING子句来显著减少某些操作生成的redo数。我们还研究了redo生成与块清除（block cleanout）和日志竞争（log contention）等问题的关系。 　　这一章的9.6节中讨论了撤销数据的作用，并介绍哪些操作会生成最多/最少的undo。最后分析“讨厌”的ORA-01555：snapshot too old（ORA-01555：快照太旧）错误，解释导致这个错误的可能原因，并说明如何避免。 　　第10章：数据库表 　　Oracle现在支持多种表类型。这一章将分别介绍每一种类型，包括堆组织表（heap organized，也就是默认的“普通”表）、索引组织表（index organized）、索引聚簇表（index clustered）、散列聚簇表（hash clustered）、嵌套表（nested）、临时表（temporary）和对象表（object），并讨论什么时候使用这些类型的表、如何使用以及为什么使用。大多数情况下，堆组织表就足够了，不过这一章还将帮助你认识到在哪些情况下使用其他类型的表更合适。 　　第11章：索引 　　索引是应用设计的一个重要方面。要想正确地实现索引，要求深入地了解数据，清楚数据如何分布，并且知道要如何使用数据。人们经常把索引当做“马后炮”，直到应用开发的后期才增加，这就会导致应用的性能低下。 　　这一章将详细分析各种类型的索引，包括B*树索引、位图索引（bitmap index）、基于函数的索引（function-based index）和应用域索引（application domain index），并讨论各种索引应该在哪些场合使用，以及哪些场合不适用。我会在11.6节回答常常被问到的一些问题，如“索引能在视图上使用吗”和“为什么没有使用我的索引”。 　　第12章：数据类型 　　有许多数据类型可供选择。这一章会逐一分析22种内置数据类型，解释这些类型是如何实现的，并说明如何以及何时使用这些数据类型。首先对国家语言支持（National Language Support，NLS）做一个简要的概述。要想充分理解Oracle中简单的串类型，必须先掌握这个基础知识。接下来再讨论广泛使用的NUMBER类型，并介绍Oracle Database 10g 对于在数据库中存储数值又提供了哪些新的选项。我们主要从历史角度介绍LONG和LONG RAW类型，目的是讨论如何处理应用中遗留的LONG列，并将其移植为LOB类型。然后会深入分析存储日期和时间的各种数据类型，讨论如何处理这些数据类型来得到我们想要的结果。这里还会谈到时区支持的有关细节。 　　接下来讨论LOB数据类型。我们会说明LOB类型的存储方式，并指出各种设置（如IN ROW、CHUNK、RETENTION、CACHE等）对我们有什么意义。处理LOB时，重要的是要了解默认情况下它们如何实现和存储，在对LOB的获取和存储进行调优时这一点尤其重要。本章的最后介绍ROWID和UROWID类型。这些是Oracle专用的特殊类型，用于表示行地址。我们会介绍什么时候可以将它们用作表中的列数据类型。（这种情况几乎从来不会出现！） 　　第13章：分区 　　分区（partitioning）的目的是为了便于管理非常大的表和索引，即实现一种“分而治之”的逻辑，实际上就是把一个表或索引分解为多个较小的、更可管理的部分。在这方面，DBA和开发人员必须协作，使应用能有最大的可用性和最高的性能。这一章介绍了表分区和索引分区。我们会谈到使用局部索引（在数据仓库中很常用）和全局索引（常见于OLTP系统）的分区。 　　第14章：并行执行 　　这一章介绍了Oracle中并行执行（parallel execution）的概念，并说明了如何使用并行执行。首先指出并行处理在什么情况下有用，以及哪些情况下不应考虑使用它。有了一定的认识后，再来讨论并行查询的机制，大多数人提到并行执行都会想到这个特性。接下来讨论PDML（parallel DML，并行DML），利用PDML，可以使用并行执行完成修改。我们会介绍PDML在物理上如何实现，并说明为什么这个实现会对PDML带来一系列限制。 　　然后再来看并行DDL。在我看来，这才是并行执行真正的闪光之处。通常，DBA会利用一些小的维护窗口来完成大量的操作。利用并行DDL，DBA就能充分利用可用的机器资源，在很短的时间内完成很大、很复杂的操作（它只需原先串行执行所需时间的很小一部分）。 　　这一章的最后将讨论过程并行机制（procedural parallelism），采用这种方法可以并行地执行应用程序代码。这里将介绍两个技术。首先是并行管道函数（parallel pipelined function），即Oracle动态地并行执行存储函数。第二个技术是DIY并行机制（DIY parallelism），利用这个技术可以把应用设计为并发地运行。 　　第15章：数据加载和卸载 　　15.1节重点介绍SQLLDR（SQL*Loader），并说明可以采用哪些方法使用这个工具来加载和修改数据库中的数据。我们会讨论加载定界数据，更新现有的行和插入新行，卸载数据，以及从存储过程调用SQLLDR。重申一遍，SQLLDR是一个完备而重要的工具，但它的实际使用也带来很多问题。15.2节主要讨论外部表，这是另外一种数据批量加载和卸载的高效方法。 　　第16章：数据加密 　　这一章将探讨对Oracle数据库中的数据加密有哪些途径。这里讨论了如何使用内置数据库包DBMS_CRYPTO完成手动“DIY”加密，不过这个内容不是重点。实际上，这里更强调的是为什么不应使用这个包。这一章的重点是Oracle数据库中透明数据加密（Transparent Data Encryption，TDE）的实现细节，强调了如何实现列级加密和表空间级加密，以及这对于开发人员或DBA有什么意义。这一章并未全面涵盖每一种可能的配置（这是Oracle文档的工作），而是提供了一些实用的实现细节，并指出这对你会有哪些影响。 　　源代码和有关更新 　　使用这本书中的例子时，你可能想亲手键入所有代码。很多读者都喜欢这样做，因为这是熟悉编码技术的一种好办法。 　　无论你是否想自己键入代码，都能从Apress网站（http://www.apress.com）的Source Code区下载本书的所有源代码。即使确实想自己键入代码，下载源代码也很有必要，你可以使用下载的源代码文件检查正确的结果是什么。如果你认为自己的录入可能有误，就可以先从这一步开始。倘若不想自己键入代码，那么除了从Apress网站下载源代码外别无选择！不论采用哪种方式，代码文件都能帮助你完成更新和调试。 　　勘误表 　　Apress极力确保文字或代码不会出错。不过，出错也是人之常情，所以只要发现并修改了错误，我们就会及时告诉你。Apress所有图书的勘误表都可以在http://www.apress.com上找到。如果你发现一个还没有报告的错误，请通知我们。Apress网站还提供了其他的信息和支持，包括所有Apress图书的代码、样章、新书预告以及相关主题的文章等。 　　 序言 　　第 1 版 序 　　“Think”（思考）。1914年，Thomas J. Watson先生加入后来成为IBM的公司时，带来了这样一个简简单单的座右铭。后来，这成为每一位IBM员工的训词，不论他们身居何职，只要需要作出决策，并利用自己的才智完成工作，就要把“Think”谨记于心。一时间，“Think”成为一个象征、一个标志，屡屡出现在出版物上，人们把它写在日历上提醒自己。而且不仅在IBM内部，就连其他一些公司的IT和企业管理者的办公室墙上也悬挂着这个牌匾，甚至《纽约客》杂志的漫画里都有它的身影。“Think”在1914年是一个很好的观念，即使在今天也同样有着重要的意义。 　　“Think different”（不同凡想）是20世纪90年代苹果公司在其旷日持久的宣传活动中提出的一个口号，想借此重振公司的品牌，更重要的是，想改变人们对技术在日常生活中作用的看法。苹果公司的口号不是“think differently”（换角度思考，暗含如何去思考），而是把“different”用作动词“think”的宾语，暗含该思考些什么（与“think big”句式相同）。这个宣传活动强调的是创造性和有创造力的人，暗示苹果电脑在支持创新和艺术成就方面与众不同。 　　我在1981年加入Oracle公司（那时还叫Relational Software公司）时，包含关系模型的数据库系统还是一种新兴技术。开发人员、程序员和队伍逐渐壮大的数据库管理员都在学习采用规范化方法的数据库设计原则。在此之后出现了非过程性的SQL语言。尽管人们对它很陌生，但无不为其强大的能力所折服，因为利用SQL语言能有效地管理数据，而以前同样的工作需要非常辛苦地编程才能完成。那时要思考的东西很多，现在也依然如此。这些新技术不仅要求人们学习新的观念和方法，还要以新的思路来思考。不论是过去还是现在，做到了这一点的人最终都大获成功，他们能最大限度地利用数据库技术，为企业遇到的问题建立有效的创新性解决方案。 　　想一想SQL数据库语言吧，历史上是Oracle首次推出了商业化的SQL实现。有了SQL，应用设计人员可以利用一种非过程性语言（或称“描述性语言”）管理行集（即记录集），而不必使用传统的过程性语言编写循环（一次只能处理一条记录）。刚开始接触SQL时，我发现自己必须“转45°”考虑问题，以确定如何使用诸如联结和子查询之类的集合处理操作来得到想要的结果。那时，集合处理对大多数人来说还是全新的概念，不仅如此，这也是非过程性语言的概念。也就是说，只需指定想要的结果，而无需指出如何得到这些结果。这种新技术确实要求我“换角度思考”，当然也使我有机会“不同凡想”。 　　集合处理比一次处理一条记录要高效得多，所以如果应用程序能以这种方式充分利用SQL，就能比那些没有使用集合处理的应用程序表现得更出色。不过，遗憾的是，应用程序的性能往往都不尽如人意。实际上，大多数情况下，最能直接影响整体性能的是应用程序设计，而不是Oracle参数设置或其他配置选项。所以，应用程序开发人员不仅要学习数据库特性和编程接口的详细内容，还要掌握新的思路，并在应用程序中适当地使用这些特性和接口。 　　在Oracle社区中，针对如何对系统调优以得到最佳的性能（或者如何最佳地使用各种Oracle特性），有许多“常识”。这种原本明智的“常识”有时却演变成为一种“传说”甚至“神话”，这是因为开发人员和数据库管理员可能不加任何批判地采纳这些思想，或者不做任何思考就盲目扩展它们。 　　比如说这样一个观点：“如果一个东西很好，那么越多越好。”这种想法很普遍，但一般并不成立。以Oracle的数组接口为例，它让开发人员只用一个系统调用就能插入或获取多行记录。显然，能减少应用程序和数据库之间传递的网络消息数当然很好。但是再想想看，到达某个“临界”点后，情况可能会改变。一次获取100行比一次获取1行要好得多，但是如果一次获取1 000行而不是100行，这对于提高整体性能通常意义并不大，特别是考虑到内存需求时更是如此。 　　再来看另一个不加判断就采纳的例子，一般主张关注系统设计或配置中有问题的地方，而不是最有可能改善性能的方面（或者是能提高可靠性、可用性或增强安全性的方面）。请考虑一个系统调优的“常识”：要尽可能提高缓冲区的命中率。对于某些应用，要尽量保证所需数据在内存中，这会最大限度地提高性能。不过，对于大多数应用，最好把注意力放在它的性能瓶颈上（我们称之为“等待状态”），而不要过分强调某些系统级指标。消除应用程序设计中那些导致延迟的因素，就能得到最佳的性能。 　　我发现，将一个问题分解为多个小部分再逐个解决，是一种很好的应用程序设计方法。采用这种方式，往往能极好地、创造性地使用SQL解决应用需求。通常，只需一条SQL语句就能完成许多工作，而你原来可能认为这些工作需要编写复杂的过程式程序才能实现。如果能充分利用SQL的强大能力一次处理一个行集（可能并行处理），这不仅说明你是一个高效率的应用程序开发人员，也说明应用程序能以更快的速度运行！ 　　最佳实践有时取决于（或部分取决于）事实的真实性。有时，随着事实的改变，这些最佳实践可能不再适用。有一句古老的格言：“要得到最好的性能，应当把索引和数据放在单独的表空间中。”我经常发现许多数据库管理员都恪守着这个格言，根本不考虑如今磁盘的速度和容量已经大为改观，也不考虑给定工作负载的特殊要求。要评价这个“规则”是否合适，应该考虑这样一个事实：Oracle数据库会在内存中缓存最近经常使用的数据库块（通常这些块属于某个索引）。还有一点需要考虑：对于给定的请求，Oracle数据库会按顺序使用索引和数据块，而不是同时访问。这说明，所有并发用户实际上应该都会执行涉及索引和数据的I/O操作，而且每块磁盘上都会出现I/O操作。可能你会出于管理方面的原因（或者根据个人喜好）将索引和数据块分置于不同的表空间中，但绝不能说这样做是为了提高性能。（Thomas Kyte在Ask Tom网站http://asktom.oracle.com上对这个主题做了深入的分析，有关文章可以在“index data table space”中查到。）从中我们可以得到一个教训，要根据事实作出决定，而且事实必须是当前的、完备的。 　　不论我们的计算机速度变得多快，数据库变得多复杂，也不管编程工具的能力如何，人类的智慧和一套正确的“思考原则”仍是无可替代的。所以，对于应用中使用的技术，尽管学习其细节很重要，但更重要的是，应该知道如何考虑适当地使用这些技术。 　　Thomas Kyte是我认识的最聪明的人之一，他在Oracle数据库、SQL、性能调优和应用设计方面具有渊博的学识。我敢肯定，Thomas绝对是“Think”和“Think different”这两个口号不折不扣的追随者。中国有位智者说过“授人以鱼，为一饭之惠；授人以渔，则终身受用”，显然Thomas对此深以为然。Thomas很乐于把自己的Oracle知识与大家共享，但他并不只是罗列问题的答案，而是尽力帮助大家学会如何思考和推理。 　　在Thomas的网站（http://asktom.oracle.com）上、发言稿中以及书中，他不断鼓励人们在使用Oracle数据库设计数据库应用时要“换角度思考”。他从不墨守成规，而坚持通过实例，用事实证明。Thomas采用一种注重实效的简单方法来解决问题，按照他的建议和方法，你将成为更高效的开发人员，能开发出更好、更快的应用。 　　Thomas的这本书不仅介绍Oracle的诸多特性，教你使用这些特性，还反映了以下简单的观点。 　　不要相信神话，要自己思考。 　　不要墨守成规，所有人都知道的事情其实很可能是错的！ 　　不要相信传言，要自己测试，根据经过证明的示例作出决定。 　　将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。 　　如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。 .　　理解理想和现实之间的差距。 　　对于公司制定的未加证实的技术标准，要敢于提出质疑。 　　要针对当前需求从大局考虑怎样做最好。 　　要花时间充分地思考。 　　Thomas建议，不要只是把Oracle当做一个黑盒。你不只是在Oracle中放入和取出数据。他会帮助你理解Oracle是如何工作的，如何充分利用它强大的能力。通过学习如何在深思熟虑之后创造性地应用Oracle技术，你会更快、更好地解决大多数应用设计问题。 　　通过阅读这本书，你会了解到Oracle数据库技术的许多新动态，还会掌握应用设计的一些重要概念。如果你确实领会了这些思想，相信你肯定也会对所面对的难题“换角度思考”。 　　IBM的Watson曾经说过：“自始以来，每一个进步都源自于思考。仅仅因为‘没有思考’，就造成全世界白白浪费了无数资金。”Thomas和我都赞同这种说法。希望你学完这本书后，利用你掌握的知识和技术，为这个世界（至少为你的企业）节省无数资金，把工作干得更出色。 　　Ken Jacobs 　　Oracle 公司产品战略部（服务器技术）副总裁，公认的“DBA博士” 　　 　　序 　　第一次接触到Oracle RDBMS是在1988年，也可能是1987年。那一天，经理在我的办公桌上放下一个小盒子，对我说了几句话，大致意思是：“这是一个刚刚进入国内的新产品，名叫Oracle。你先试用几个星期，看看它适合做些什么。” 　　那个版本可能是5.0.22，当时学习Oracle可比现在简单多了。全套的印刷手册（包括Forms 2.0和SQL*Report等）可以放在一个小小的公文包里，create table语句的文档只有大约3页而已。 　　如果查看11.2 SQL参考手册的PDF文件，会发现从16-6页开始，直到16-79页全都是create table语句的文档，总共有74页。我最后一次查看9i手册时，总页数已经超过了20 000页。我想，对于10g和11g，文档的总页数应该不会低于这个数字。 　　由于5.0.22只有3本相当薄的手册，所以没过多久我就全面了解了Oracle能够做些什么以及如何高效地完成工作。那时没有太多选择余地，所以出错的机会也不多。不过如今Oracle内核已经“深埋”在不计其数的选项和特性之下，这使得Oracle的学习困难重重，该如何下手呢？更糟糕的是，着手学习时，我们真正需要了解的细节并不是一目了然的，它往往被其他大量信息所“掩盖”，当然了解这些信息本身并不是坏事，但它们对于入门来说并不是至关重要的。 　　答案很简单。 　　第1步：阅读概念手册，对内容有个大致了解。 　　第2步：读Tom Kyte的这本书，通过边学习边试验，从一个初次尝试 “select ‘hello world’ from dual”的“菜鸟”转变成Oracle高手，有朝一日也能自信满满地说出一些“高深”言论，比如：“出于某个原因，我们应该使用一个分区IOT，将这些列放在这个表的溢出区中。” 　　Tom的这本书集三点于一身：一种轻松交流的风格，使读者能够更容易地了解技术细节，在知道“怎样做”的同时还能理解“为什么这样做”；一种结构化的“叙事方式”，你会看到，相关描述都针对同一个目标，而不是把支离破碎的技巧简单地汇集在一起；一组精心组织的示范说明，让你了解Oracle的工作原理，还会教你怎样做以及怎样思考。 　　仅以索引为例。索引有许多种，首先需要简要介绍这些不同类型。例如，如果对B-树索引的具体工作原理有所认识，会很有好处，这样我们才能更好地了解这种索引的优缺点。然后可以转向基于函数的索引，也就是“尚不存在的数据”的索引。由此我们不仅能知道Oracle能够做什么，还会了解通过对Oracle的处理我们还能进一步做些什么。接下来可以看到如何把这些综合起来，创建一个确保数据子集唯一性的索引。还会看到如何在一个大型数据集上创建维护要求不高的小索引，只标识真正想要访问的数据，将优化器生成“愚蠢”执行计划的风险减至最低。 　　基本说来，手册中都涵盖了这些内容，不过，我们必须具备敏锐的洞察力，能够从纷繁的命令中挑出我们想要的内容，查看如何使用这些命令为实际问题建立解决方案。Tom Kyte就展示了这种洞察力，而且还鼓励我们更进一步形成自己的认识。 　　坦率地讲，如果全世界每一位DBA和开发人员都精心研读了Tom Kyte的这本书，我可能就得改行为SQL Server用户提供咨询服务了，因为需要Oracle咨询的客户肯定会显著减少。 　　Jonathan Lewis 　　英国Oracle用户群负责人 　　 媒体评论 　　“本书能够帮助你发挥Oracle技术的最大能量……毋庸置疑，这是最重要的Oracle图书之一，绝对值得拥有。” 　　——Ken Jacobs 　　Oracle公司产品策略部（服务器技术）副总裁，公认的DBA博士 　　“真是一本绝妙的书，包含大量关于Oracle技术的真知灼见。” 　　——Sean Hull 　　
Visual Studio程序员箴言--详细书签版
CruiseYoung提供的带有详细书签的电子书籍目录 http://blog.csdn.net/fksec/article/details/7888251 Visual Studio程序员箴言 原书名： Microsoft Visual Studio Tips 原出版社： Microsoft Press 作者： (美)Sara Ford 译者： 谢俊 出版社：人民邮电出版社 ISBN：9787115215727 上架时间：2009-12-31 出版日期：2010 年1月 开本：16开 页码：205 版次：1-1 所属分类：计算机 > 软件与程序设计 > .NET > Visual Studio.NET 内容简介 　　visual studio是微软公司推出的、目前最流行的windows平台应用程序开发环境。本书介绍了各种visual studio使用技巧，全书共7章，依次介绍了编辑器、查找功能、环境布局、设计 工具以及解决方案、其他项目与调试方面的技巧。 　　 本书的作者是一位经验丰富的visual studio测试工程师，她将自己平日博客上的visual studio使用技巧归纳成书，并通过图例让读者对技巧的作用了如指掌。无论是对visual studio 初学者还是经验丰富的用户来说，了解、掌握并在实际工作中使用这些技巧都能在开发中达到事半功倍的效果。 作译者 作者: Sara Ford 　　Sara Ford 作为Visual Studio核心团队负责测试的软件设计工程师，Sara Ford分析了Visual Studio核心环境中几乎所有的功能。她从2007年开始在自己的博客上发表”Visual Studio 每日一贴”系列文章，结果大受欢迎，并促成了本书的诞生。Sara计划将本书的稿费以奖学金的形式捐赠给她的家乡——曾被卡特琳娜飓风摧毁的密西西比州的WaVeland。 目录 封面 -30 序言 -25 致谢 -23 关于作者 -22 前言 -20 目录 -14 第1章　编辑器的基础知识 1 1.1　基本编辑 1 1.1.1　文本编辑 1 技巧1.1　避免意外复制一个空白行 1 技巧1.2　通过剪贴板环来循环粘贴不同内容 2 技巧1.3　使用Ctrl+Enter组合键在上方插入一行，使用Ctrl+Shift+Enter组合键在下方插入一行 3 技巧1.4　使用Ctrl+W组合键选择当前单词 3 技巧1.5　使用Ctrl+Delete组合键删除下一个单词，使用Ctrl+Backspace组合键删除前一个单词 3 技巧1.6　使用Ctrl+L组合键剪切当前行，使用Ctrl+Shift+L组合键删除当前行 4 技巧1.7　删除一行开头的水平空白 4 技巧1.8　将代码或文本拖动到新位置 5 技巧1.9　右键拖动代码可将代码移动或复制到某处 6 技巧1.10　在编辑器中调换字符、单词和行的顺序 6 技巧1.11　在编辑器中使用键盘快捷键来改变单词的大小写 7 1.1.2　撤销/重复 7 技巧1.12　使用标准工具栏上的撤销堆栈 8 1.2　滚动与导航 8 1.2.1　滚动 8 技巧1.13　使用鼠标滚轮在各个方向上滚动 8 技巧1.14　在不滚动的情况下跳到编辑器中当前视图的顶部或底部 8 技巧1.15　隐藏编辑器中的垂直和水平滚动条 10 1.2.2　在编辑器内和编辑器之间进行导航 10 技巧1.16　通过返回标记在编辑器中进行向前和向后定位 10 技巧1.17　使用撤销操作将光标跳回到上一个插入点 11 技巧1.18　通过键盘访问导航栏 12 技巧1.19　拆分窗口和新建窗口 12 技巧1.20　使用F6在编辑器内的拆分窗格之间跳转 13 技巧1.21　在编辑器内启用URL定位 14 技巧1.22　使用Ctrl+G时不弹出“转到行”对话框 14 1.2.3　自动换行和虚空格 15 技巧1.23　启用自动换行 15 技巧1.24　启用虚空格 15 1.3　编辑器字体和颜色 16 1.3.1　字体大小 16 技巧1.25　增大编辑器中工具提示的字体大小 16 技巧1.26　将宏绑定到键盘快捷键(或者说，如何快速增大或减小文本编辑器的字体大小) 17 1.3.2　字体和颜色 17 技巧1.27　将编辑器背景改为黑色 17 技巧1.28　“工具”→“选项”→“环境”→“字体和颜色”中“自动”和“默认值”之间的差别 18 技巧1.29　改变书签的颜色 20 1.3.3　可见提示 21 技巧1.30　跟踪编辑器中的变化 21 技巧1.31　在编辑器中显示行号 21 技巧1.32　查看可见空白 22 1.4　打印 22 打印选项 23 技巧1.33　打印行号 23 技巧1.34　打印黑体 23 技巧1.35　把文件路径打印为页眉 24 1.5　状态栏 24 状态栏选项 24 技巧1.36　隐藏状态栏 25 第2章　让编辑器的使用得心应手 26 2.1　高级编辑 26 2.1.1　选择 26 技巧2.1　使用编辑器中的块/列选择 26 技巧2.2　按Esc键时跳转到所选文本的开始处 27 技巧2.3　使用Ctrl+=键选择从当前光标位置到最后一个返回标记之间的所有代码 27 技巧2.4　在编辑器中交换当前的定位点位置 28 2.1.2　注释 28 技巧2.5　使用键盘快捷键快速注释和取消注释代码 28 2.1.3　设置格式 29 技巧2.6　在编辑器中显示导引线以帮助您设置代码格式 29 技巧2.7　设置文档、选定的文本或者只是当前行的格式 30 技巧2.8　保留制表符或者插入空格 30 技巧2.9　将空格转换为制表符和将制表符转换为空格 30 技巧2.10　从文本编辑器工具栏上增加或减少行缩进 31 技巧2.11　智能缩进与块缩进之间有什么区别 32 2.1.4　大纲显示 32 技巧2.12　折叠和展开代码 32 切换大纲显示展开 32 切换所有大纲显示 33 停止大纲显示 33 启动自动大纲显示 34 折叠到定义 34 技巧2.13　剪切并粘贴一个折叠的代码块 34 技巧2.14　在不关闭大纲显示的情况下隐藏大纲显示(选定内容的边距) 35 2.1.5　模拟 36 技巧2.15　启用Emacs和Brief编辑器模拟 36 2.1.6　二进制编辑器 36 技巧2.16　在二进制编辑器内打开内容 37 2.1.7　分隔符突出显示和大括号匹配 37 技巧2.17　“自动突出显示分隔符”选项的功能是什么 38 技巧2.18　改变大括号匹配的颜色 38 2.1.8　清理未使用的代码 39 技巧2.19　移除未使用的using语句 39 2.1.9　自动恢复 39 技巧2.20　在意外关机时Visual Studio自动恢复文件 40 2.1.10　文件扩展名 41 技巧2.21　针对指定文件扩展名支持语法突出显示功能 41 2.2　打开文件 42 打开文件和编辑器窗口 42 技巧2.22　打开文件时重用同一个编辑器窗口 42 技巧2.23　在编辑器中自动刷新已打开的文档 42 技巧2.24　在Visual Studio中编辑只读文件 43 技巧2.25　自定义“文件”→“打开”→“文件”对话框打开的目录 44 技巧2.26　自定义“最近的文件”列表中显示的项数(以及在何处找到这些列表) 44 2.3　书签 45 管理书签 45 技巧2.27　设置书签并在多个书签之间导航 45 技巧2.28　在“书签”窗口中，如何在书签文件夹之间导航 46 技巧2.29　为快速查找的所有结果创建书签 46 2.4　IntelliSense 47 语句完成、参数信息和完成单词 47 技巧2.30　使用Ctrl+J键调用语句完成 48 技巧2.31　显示函数的参数信息 48 技巧2.32　显示函数的快速信息 48 技巧2.33　完成一个单词 49 技巧2.34　增大语句完成提示信息的字体大小 49 技巧2.35　调整语句完成对话框的大小 49 技巧2.36　在语句完成对话框使用键盘切换“通用”和“全部”选项卡 50 技巧2.37　默认关闭IntelliSense 50 2.5　代码段 50 使用代码段 51 技巧2.38　使用Ctrl+K、Ctrl+X键插入代码段 51 技巧2.39　通过快捷关键字插入代码段 51 技巧2.40　按Tab Tab键插入代码段 52 技巧2.41　浏览代码段和添加新代码段 53 技巧2.42　修改代码段中的默认值和变量 54 技巧2.43　与团队成员共享代码段 55 技巧2.44　围绕一块代码插入代码段 55 第3章　找到目标内容 57 3.1　通过键盘进行搜索 57 3.1.1　渐进式搜索 57 技巧3.1　体验渐进式搜索的强大功能 57 3.1.2　当前词搜索 58 技巧3.2　在不打开“查找和替换”窗口的情况下，使用Ctrl+F3键搜索当前选中的单词 58 技巧3.3　不自动搜索当前选中的单词 58 3.1.3　重复上次搜索 59 技巧3.4　使用F3键搜索上次的搜索内容 59 3.2　快速搜索 59 3.2.1　快速查找 59 技巧3.5　使用Ctrl+F键在当前文档中进行快速查找 60 技巧3.6　使用“查找”组合框在当前文档中进行快速查找 60 技巧3.7　自定义“查找”组合框(Ctrl+D)搜索 60 3.2.2　快速替换 61 技巧3.8　使用Ctrl+H键打开“快速替换”窗口 61 技巧3.9　在首次搜索到匹配项之后隐藏“快速查找/快速替换”窗口 61 3.2.3　快速查找符号 62 技巧3.10　搜索符号 62 技巧3.11　通过Shift+Alt+F12键使用“查找符号”功能 62 3.3　在文件中查找 63 3.3.1　在文件中查找 63 技巧3.12　在文件中进行查找 63 技巧3.13　自定义要在哪个文件中进行查找 63 技巧3.14　停止“在文件中查找”搜索 65 技巧3.15　替换文件中出现的所有搜索字符串 65 3.3.2　查找和替换 66 技巧3.16　停靠“查找和替换”窗口 66 3.3.3　查找结果窗口 66 技巧3.17　使用F8键在“查找结果”窗口内进行定位 66 技巧3.18　显示和隐藏查找消息 67 技巧3.19　浏览“查找符号”的结果 68 3.4　其他搜索选项 68 3.4.1　隐藏文本 68 技巧3.20　在编辑器中搜索隐藏文本 68 3.4.2　搜索范围 69 技巧3.21　在当前项目或整个解决方案中进行搜索 69 3.4.3　正则表达式 69 技巧3.22　在搜索时使用通配符和正则表达式 69 第4章　管理环境布局 71 4.1　文档窗口 71 4.1.1　文件选项卡频道 72 技巧4.1　使用Ctrl+Alt+下箭头打开文件选项卡频道的文件下拉菜单 72 技巧4.2　使用文件选项卡频道上的“除此之外全部关闭” 72 技巧4.3　从文件选项卡频道复制文件的完整路径 73 技巧4.4　直接打开包含活动文件的Windows资源管理器 74 技巧4.5　只关闭选定的文件 74 技巧4.6　在什么情况下，文件选项卡频道的下拉按钮会改变图标 75 4.1.2　IDE导航器 76 技巧4.7　使用Ctrl+Tab键打开IDE导航器，快速查看并浏览所有打开的文件和工具窗口 76 技巧4.8　禁用IDE导航器 76 4.1.3　键盘导航 77 技巧4.9　使用Ctrl+F6键和Ctrl+Shift+F6键在打开的文档窗口间导航 78 技巧4.10　使用Ctrl+F4键关闭编辑器中当前打开的文档 78 4.1.4　MDI模式 78 技巧4.11　进入MDI模式 78 技巧4.12　在“窗口”对话框中显示“水平平铺”和“垂直平铺”按钮 79 4.2　工具窗口 80 4.2.1　可停靠状态 80 技巧4.13　从9个IDE工具窗口停靠目标中进行选择 80 技巧4.14　只取消一组工具窗口中一个窗口的停靠 81 技巧4.15　将工具窗口停靠在IDE顶部 82 技巧4.16　以新奇而疯狂的方式，使用停靠目标来停靠工具窗口 82 4.2.2　自动隐藏状态 83 技巧4.17　使用一条命令自动隐藏所有工具窗口 83 技巧4.18　自定义按下工具窗口图钉时的行为，自动隐藏工具窗口还是整个工具窗口选项卡组 84 技巧4.19　通过工具窗口自动隐藏显示自动隐藏的工具窗口 85 技巧4.20　双击工具窗口的标题栏可重新停靠该工具窗口 85 技巧4.21　使用shift+单击自动停靠处于自动隐藏的工具窗口 86 技巧4.22　加快或减慢工具窗口从停靠位置滑出的速度 88 4.2.3　浮动状态 88 技巧4.23　为什么要让工具窗口处于浮动状态 88 4.2.4　选项卡式文档状态 89 技巧4.24　使用选项卡式文档最大化工具窗口 89 4.2.5　键盘导航 90 技巧4.25　使用Alt+F7键和Alt+Shift+F7键移到下一个或前一个工具窗口 90 技巧4.26　使用Alt+F6键和Alt+Shift+F6键在打开的工具窗口间循环 90 技巧4.27　使用Ctrl+PgUp键和Ctrl+PgDn键在工具窗口组中的各个工具窗口间导航 90 4.2.6　隐藏状态 91 技巧4.28　自定义单击X按钮时对工具窗口或工具窗口选项卡组的操作 91 4.2.7　隐藏的键盘快捷键 92 技巧4.29　使用键盘拖动工具窗口 92 技巧4.30　使用键盘调整工具窗口的大小 92 技巧4.31　访问工具窗口内的工具栏 93 技巧4.32　使用Shift+Esc键关闭工具窗口 94 4.3　窗口布局 94 4种窗口布局 94 技巧4.33　只导出窗口布局 94 技巧4.34　快速进入全屏模式 95 技巧4.35　访问能够自定义的文件窗口布局模式 95 4.4　工具栏和上下文菜单 96 4.4.1　工具栏 96 技巧4.36　将工具栏变为浮动 96 技巧4.37　隐藏或显示任何工具栏的默认按钮 97 技巧4.38　随时显示任意工具栏 98 技巧4.39　显示“工具”→“自定义”对话框时，可切换和交换工具栏上的按钮 98 技巧4.40　在工具栏的工具提示中显示快捷键 99 4.4.2　上下文菜单 99 技巧4.41　自定义上下文菜单上的命令 99 第5章　了解更多的设计工具(第1部分) 101 5.1　“工具”窗口 101 5.1.1　命令窗口 101 技巧5.1　从“命令”窗口运行Visual Studio命令 101 技巧5.2　在“命令”窗口”中进行搜索 102 技巧5.3　记录“命令”窗口的会话　103 技巧5.4　从“命令”窗口运行外部可执行程序 103 技巧5.5　创建命令别名 104 5.1.2　“输出“窗口 105 技巧5.6　使用F8键和Shift+F8键在“输出”窗口中的错误之间导航 105 技巧5.7　双击“输出”窗口中的消息直接跳到代码中对应的位置 106 技巧5.8　使用键盘跳至“输出”窗口内的不同窗格 106 技巧5.9　在生成期间停止“输出”窗口的显示 107 技巧5.10　在“输出”窗口启用自动换行 107 技巧5.11　自定义“输出”窗口的颜色方案 108 技巧5.12　将调试消息重定向到“输出”窗口 109 技巧5.13　不能在“输出”窗口启用“停止搜索” 109 5.1.3　工具箱 110 技巧5.14　将代码拖放到工具箱的“常规”选项卡 110 技巧5.15　为什么每个工具箱分组都有一个“指针”控件 111 技巧5.16　不让工具箱自动填充在解决方案中找到的所有组件 111 技巧5.17　使用*展开工具箱的全部组件，使用/折叠工具箱的全部组件 112 技巧5.18　使用Ctrl+上箭头和Ctrl＋下箭头在工具箱的控件组之间移动 113 技巧5.19　按字母顺序对工具箱中的组件排序 113 技巧5.20　在工具箱的图标视图和列表视图之间切换 114 技巧5.21　使用“全部显示”找到已隐藏的工具箱控件 114 技巧5.22　使用Ctrl+C键复制工具箱选项卡中的控件，然后用Ctrl+V键将该控件粘贴到另一个工具箱选项卡 115 技巧5.23　新建工具箱选项卡 116 5.1.4　任务列表 117 技巧5.24　使用任务列表创建独立于代码的用户任务 117 技巧5.25　为任务列表中的用户任务分配优先级 118 技巧5.26　在任务列表中创建和查看TODO注释 118 技巧5.27　在任务列表中创建快捷方式 119 技巧5.28　在任务列表中显示HACK、UNDONE和自定义标记 120 技巧5.29　将删除用户任务时的提示禁用 121 技巧5.30　在任务列表上显示完整的文件路径 122 技巧5.31　创建可在不同任务列表类别之间进行导航的键盘快捷键(使用视图.下一任务和视图.上一任务) 123 5.1.5　对象浏览器 124 技巧5.32　使用Ctrl+Alt+J键打开“对象浏览器”窗口 124 技巧5.33　在“对象浏览器”中只显示解决方案中的组件 124 技巧5.34　在“对象浏览器”中创建自定义的组件列表 125 技巧5.35　直接从“对象浏览器”向解决方案添加引用 126 技巧5.36　使用前进/后退按钮在“对象浏览器”中导航 127 技巧5.37　创建键盘快捷键，从“对象浏览器”向解决方案添加引用 127 技巧5.38　自定义“对象浏览器”的“对象”窗格和“成员”窗格 128 技巧5.39　选择是否在“对象浏览器”中显示基类型 129 技巧5.40　在“对象浏览器”中隐藏成员和类型或者显示已隐藏的成员和类型 130 技巧5.41　将方法和类型标记为“隐藏”，避免它们在Microsoft IntelliSense或“对象浏览器”中出现 130 技巧5.42　“对象浏览器”设置中“显示其他成员”中“其他”的含义 131 技巧5.43　在“对象浏览器”的“成员”窗格中不显示所有继承的成员 131 技巧5.44　在“对象浏览器”中显示扩展方法 132 技巧5.45　在“对象浏览器”中搜索对象的两种基本方法 132 技巧5.46　在“对象浏览器”中用F12键跳到选定的定义 133 技巧5.47　在“对象浏览器”中使用“查找符号”搜索(Shift＋F12键) 133 技巧5.48　在“对象浏览器”中使用自动查找匹配选择支持 134 技巧5.49　将所有“对象浏览器”自定义导出到.vssettings文件中 135 技巧5.50　为何“对象浏览器”有很多可以绑定的命令(以及如何创建一个可清除搜索结果的键盘快捷键) 135 技巧5.51　在“对象浏览器”中使用全局命令视图.前进(Alt+右箭头)和视图.后退(Alt+左箭头) 136 第6章　了解更多的设计工具(第2部分) 138 6.1　对话框 138 6.1.1　导入和导出设置 138 技巧6.1　找出上次重置的开发设置 139 技巧6.2　通过“工具”→“导入和导出设置”重置环境设置 139 技巧6.3　“‘新建项目’对话框首选语言”类别中包含哪些设置 141 技巧6.4　在“导入和导出设置”→“重置”页面的列表中添加自己的文件 142 技巧6.5　重置设置和导入设置之间有何区别 143 技巧6.6　进行导入或重置之前保存当前设置 144 技巧6.7　Visual Studio每次关闭时自动保存所有当前设置 145 技巧6.8　导出设置时可以从最后一个向导页面上复制完整的文件路径 146 技巧6.9　使用团队设置保持Visual Studio设置在不同计算机上实现同步 147 6.1.2　外部工具 147 技巧6.10　从IDE运行外部工具 148 技巧6.11　在列表中添加自己的外部工具 149 技巧6.12　重新排列外部工具列表并创建键盘助记符 150 技巧6.13　在“输出”窗口中显示外部工具的文本 150 技巧6.14　使用外部工具标记 152 技巧6.15　运行外部工具时提示输入参数 152 6.2　查找组合框 153 通过查找组合框运行命令 153 技巧6.16　体验使用“查找”组合框的乐趣 153 技巧6.17　使用Ctrl+/键在“查找”组合框内运行Visual Studio命令 154 技巧6.18　在不使用工具窗口或对话框的情况下，打开解决方案中的文件 155 技巧6.19　通过“查找”组合框设置函数断点 155 6.3　起始页 156 起始页窗口 156 技巧6.20　修改Visual Studio起始页上的RSS源 156 技巧6.21　自定义Visual Studio启动时打开的内容(或者如何让Visual Studio打开时不显示起始页) 157 第7章　了解解决方案和其他项目及调试技巧 158 7.1　项目和解决方案系统 158 7.1.1　多定向 158 技巧7.1　Visual Studio 2008支持.NET Framework的多定向 159 7.1.2　项目 159 技巧7.2　修改默认的新建项目位置 160 技巧7.3　在“新建项目”对话框中，可以在小图标和大图标之间切换 160 技巧7.4　使用解决方案文件夹隐藏项目 161 技巧7.5　创建临时或“用完即扔”的项目 162 技巧7.6　隐藏或显示“项目位置不受信任”消息框 163 7.1.3　生成配置 163 技巧7.7　使用简化生成配置 163 7.1.4　解决方案资源管理器 165 技巧7.8　在解决方案资源管理器中显示杂项文件项目 165 技巧7.9　解决方案资源管理器中支持自动查找匹配选择 166 技巧7.10　在解决方案中添加解决方案 166 技巧7.11　在解决方案资源管理器中重命名文件时，自动在整个项目中执行重命名 167 技巧7.12　在解决方案资源管理器中隐藏或显示一个解决方案 168 技巧7.13　让解决方案资源管理器始终显示(或者不显示)编辑器中当前打开的文件 168 7.2　调试 168 7.2.1　跟踪点 169 技巧7.14　无需编辑代码，只要使用跟踪点就能记录PrinfF()或Console.WriteLine()的信息 169 7.2.2　断点 170 技巧7.15　单击指示器边距设置断点 170 技巧7.16　按F9键在当前行上设置断点 171 技巧7.17　使用Ctrl+F9键启用或禁用断点 171 技巧7.18　设置有条件的断点 172 技巧7.19　使用断点筛选器中断正确的进程 173 技巧7.20　按Ctrl+B键在目标函数上设置断点 174 技巧7.21　按Ctrl+Alt+B键打开断点窗口 174 技巧7.22　按Ctrl+Shift+F9键删除所有断点 175 技巧7.23　禁用删除所有断点之前的警告消息 175 7.2.3　数据提示 176 技巧7.24　使用数据提示编辑变量的内容 176 7.2.4　多个项目 177 技巧7.25　在解决方案资源管理器中选择启动项目 177 技巧7.26　启动调试多个项目 178 技巧7.27　在一个进程中断时则中断所有进程 179 7.2.5　编译和调试窗口 179 7.2.6　错误列表 179 技巧7.28　使用Ctrl+Shift+F12键查看错误列表中列出的下一个错误 180 技巧7.29　自定义错误列表视图 180 技巧7.30　直接从错误列表查看一个错误所在的文档 181 技巧7.31　在错误列表和任务列表中进行多列排序(次要排序等) 181 技巧7.32　将显示错误、警告和消息的3个按钮绑定到键盘快捷键 182 技巧7.33　生成失败后显示或隐藏错误列表 183 7.2.7　监视窗口 183 技巧7.34　使用“监视”窗口快速修改变量的值 183 技巧7.35　在调试窗口中以十六进制格式查看数值 184 7.2.8　“即时”窗口 185 技巧7.36　使用“即时”窗口作为一个方便的计算器或者调试器的辅助调试器 185 附录A　Visual Studio背景资料 187 Visual Studio问答 187 为什么可执行文件叫做devenv.exe而不是visualstudio.exe？ 187 Visual Studio标志是一个无穷符号还是麦比乌斯带？ 188 Visual Studio标志中的颜色有什么意义？ 188 “解决方案资源管理器”在IDE的左边还是右边？ 188 “解决方案”的概念是怎么来的？ 189 为什么工具窗口选项卡显示在工具窗口组的底部，而文件选项卡显示在文件选项卡频道的顶部？ 189 为什么是Common7，而不是Common8或Common9？ 190 附录B　通过博客发布技巧的技巧 191 “每日一贴”秘密行为准则 191 技巧1　每条技巧专门讲述一种特定操作 191 技巧2　每条技巧配一幅图片 192 技巧3　引用可信的参考资料 192 技巧4　尽可能地分享和收集故事 192 技巧5　尽可能提前安排好要写的技巧 192 技巧6　在破晓前发表技巧 192 技巧7　使用Windows Live Writer编写和安排技巧 193 附录C　软件测试技巧 194 测试人员的5大生存技巧 194 技巧1　绝对不要做任何假定 194 技巧2　从漏掉的bug吸取教训 196 技巧3　尽可能地帮助开发人员 196 技巧4　关闭bug时留下正确的注释 197 技巧5　以书面形式记录下bug 197 附录D　我是如何开始从事编程的 198 抓住怪兽 198 高呼“YoHo” 199 在TI-99 4A上编程 200 玩任天堂游戏 200 用代码解决数学问题 202 大学中的学习 202 进入Microsoft 203 在Microsoft的面试 203 技巧252　让语句声明窗口变成透明的 205 前言 　　本书包含的251条最佳技巧可以帮助读者掌握Visual Studio环境的所有细节。设想一下使用最简单的例子解释对所有语言通用的“工具选项”设置，并通过实例让您对核心环境了如指掌 。本书中的技巧探讨了集成开发环境(Integrated Development Environment，IDE)的这些方面，让您以上的设想成为现实。 　　开始阅读本书之前，您必须知道当前使用的是哪种开发设置，这样才能知道应该使用哪些键盘快捷键。 　　我编写这些技巧时使用的是常规开发设置和美国英语键盘布局。您可以使用技巧6．1了解当前使用的开发设置，并通过技巧6．2重置您的设置，这样才能直接按照我的指示操作并与我使 用相同的键盘快捷键。 　　如果要使用您的当前设置，请阅读本节末尾的技巧0．0，了解可以使用的键盘快捷键是哪些。没错，我在大学里学的专业就是数学，因此我会从0开始计数。 　　本书的起源 　　2005年3月，当时我与VisualStudio核心编辑器的程序经理SeanLaberee共用一间办公室。有一天，当我走出办公室准备去吃午饭时，他显示器上“每日一贴”的字眼吸引了我。我不想让 Sean觉得我是有意看他的显示器，但与此同时，我被将这种想法付诸于行动的念头深深吸引住了。 　　我回来的时候，向他打听了关于这个“每日一贴”的事情。他的想法是把这些“您知道吗”风格的技巧公布在Visual Studio的起始页上。而我建议使用我的博客每天发表一条编辑器技巧 ，先试验几个月。最近我加入了编辑器小组，并成为一名软件测试人员，然后惊讶于编辑器内居然存在那么多我不知道的功能。 　　现在Rob Caron也加入了进来，他是Visual Studio的一名营销经理。Rob在MSDNRSS源上注意到了这个试验，并鼓励我放开手脚，每周推出一系列关于Visual Studio的更多方面的技巧。他 更加重视这些技巧，还把它们放到了Visual Studio主页上。 　　2005年8月27日是个星期六，当看到这些技巧出现在产品的Web站点上时，我抑制不住自己的激动之情，打电话回家让我的家人到网站上去看，让他们一同分享我的喜悦。但激动没有维持 多久，我妈妈就通知我说“大块头”已经到了墨西哥湾，正朝着新奥尔良而去。我说，“哦，真的吗?今年我一直没怎么留意飓风季。它叫什么名字啊?”从此以后我再也不想听见卡特琳娜这 个名字。 　　2007年春天，在从负责测试的软件设计工程师转为程序管理岗位后，我决定再度尝试为Visual Studio 2008编写每周技巧系列。RobCaron再次加入了进来。他说，“你知道，每天推出一 条技巧一定会相当震撼。”对于这个巨大的挑战，我居然完全没法说“不”。 　　在推出Visual Studio 2008“每日一贴”系列文章期间，写一本书并把作者版税捐出去的想法一直在我心里酝酿着，即使我已经离开Visual Studio团队而转投CodePlex团队也是如此。很 幸运，多亏在接下来的几个月里，我博客上的很多读者提出让我写一本书的请求，我意识到时机终于来了。 　　本书面向的受众 　　本书所介绍的技巧将目标定为Visual Studio核心环境中的功能，所以它们对于所有编程语言都是通用的。为了编写这些技巧，我将这些IDE的通用功能领域细分为非常小的功能块。因此 ，有些技巧探讨的是Visual Studio的细节方面，而有些技巧则探讨的是不那么明显或者说较为模糊的领域。换言之，我的目标是捕捉Visual Studio的所有细节，这样我们都能分享关于IDE工 作方式的相同基本知识。 　　本书的组织结构 　　本书中的各章对应于我们Visual Studio核心QA团队针对VisualStudio 2005产品周期，对于功能领域进行的内部划分。有些功能领域内容太多，例如编辑器，所以不得不将它分为几章讲 述。其他各章都能够很好地根据功能进行分类，例如第5章和第6章中的工具窗口与对话框部分。 　　每章中的技巧均按照顺序进行编号。例如，第3章共包含23条技巧，所以技巧的编号是依次从技巧3．1、技巧3．2开始，一直到技巧3．23。我们认为如果对于技巧进行全书统一编号，如 技巧103，或者将技巧的编号分解到子部分，如技巧3．4．3，引用起来都不如技巧3．23方便。 　　另外，您还可以在部分技巧中看到我写的“作者旁述”。我在其中与大家分享了一些与技巧有关的个人信息，既有回顾过去，关于该功能是如何测试的FYI(For Your Informantion，供您 参考)、关于编写“每日一贴”系列技巧的故事，也有对于西雅图天气的抱怨。 　　最后，我决定赠予您一些不错的新奥尔良风格的赠品——一些额外的附加内容，免费的。我在本书内包含了一些附录，并在其中分享了更多Visual Studio之外的技巧，例如编写“每日一 贴”系列，作为软件测试人员如何挺过去以及从IDE的创造者们那里听来的故事。 　　系统要求 　　本书最适合Microsoft Visual Studio 2005和Microsoft Visual Studio 2008。所有技巧均能用于Visual Studio 2005，除非技巧中特别指出该功能是Visual Studio 2008所特有的。 .　　联系作者 　　您可以访问我博客上对应的“每日一贴”系列文章，地址是http：／／biogs．msdn．com／saraford，上面还有读者给出的评论。 　　如果您正在寻求对于键盘快捷键、用户界面上找不到的部分或者似乎不可用的命令的支持，请参考技巧0．0、技巧6．1和技巧6．2。我编写这些技巧时使用的是常规开发设置，所以用户 界面与您所使用的开发设置可能会略有不同。 序言 　　撰写本书之际，世界各国人民正在中国北京欢聚一堂，共庆2008年夏季奥运会这个盛大的节日。运动员花费了数年时间将他们的身体和运动状态调整到最佳，正是为了这一刻做好准备。 那些在各个项目上获得金牌的选手将会定格在一个个辉煌的瞬间里。 　　尽管以最快速度完成编程任务一般不会授予奖牌，但您手上拿着的这本书可以帮助您更加高效地使用Visual Studio。本书中的很多技巧只能为您节省几秒钟或更少时间，但是作为开发人 员，我们都知道对于一个要执行几千次的例程而言，即使是最微不足道的优化也能带来意想不到的好处。 　　纵观本书，Sara所讲Visual Studio中的很多功能都是您从未听说过，或者已经长时间遗忘的。尽管我在Microsoft与VisualStudio打交道已经有将近10年时间，但Sara的博客依然暴露出 了我在知识方面的不足。无论您是自从20世纪90年代以来就一直使用VisualStudio，还是首次安装它，都可以从本书中找到自己需要的技巧。 　　直到我读到本书的原稿后，我才意识到我在Sara的“Visual Studio每日一贴”系列文章和在本书中扮演的角色。我很高兴有机会与她分享这些体验。知道Sara将继续本书内容的撰写让人 感到很鼓舞(我并不惊讶)。她还要帮助她家乡的人们追求他们的软件事业，这跟本书帮助开发人员更好地使用Visual Studio的原则正好不谋而合。 　　“Go，Sara，go!” 　　Rob Caron 　　2008年8月写于华盛顿州雷蒙德市 媒体评论 　　“如说Visual Studio是IDE之王，那么Sara Ford就是我们的王后。她收集了几百条最佳的Visual Studio技巧，并在其中加入了自己的见地、历史环境和幽默感等各方面的元素。本书值 得一读!” 　　Scott Hanselman，Microsoft开发人员部门社区联络人 　　“更快地写出更好的代码!这就是Visual Studio能够提供给您的帮助，但如何才能成为高效的专家呢?Sara的‘Microsoft Visual Studio技巧大全’一书充满了能够节省时间的优秀技巧 。我特别喜欢贯穿全书的‘作者旁述’内容。读完本书后，您的开发生产力每天都能提高。” 　　Joe Stagner，Microsoft高级程序经理 　　“每位VS开发人员都能够在这本新书中找到节省时间的技巧。采用这些技巧之后，就能将更多时间花在编写代码的主要工作上!” 　　Scott Wiltamuth，Microsoft Visual Studio合作伙伴程序经理 　　“纵观本书，SaraFord公开并演示了数以百计的Visual Studio特性和功能，可以帮助您节省最为宝贵的资源——时间。” 　　Rob Caron，Microsoft开发人员营销 　　“即便是我们中那些直接使用Visual Studio工作的人也很少能熟悉该产品的所有功能，尤其是快速访问这些功能的快捷方式，因此像这样的一本技巧大全是很有价值和最受欢迎的!” 　　Pat Brenner，Microsoft高级软件设计工程师 　　“Sara Ford的活力、专业技能和热情使她成为所有人最喜欢的Visual Studio IDE信息来源。她在如何更加高效地使用Visual Studio方面储备了异常丰富的知识，并在本书中无私地与我 们分享了这些知识。” 　　Charlie Calvert，Microsoft C#社区程序经理 　　“Sara的技巧涵盖了Visual Studio的方方面面，有些功能我甚至都不知道它们的存在，这些技巧对于初学者和高级程序员而言都是必不可少的。” 　　Beth Massi，Microsoft Visual Studio社区程序经理 　　“本书是一个珍贵的百宝箱，在我处理代码时为我省下了大量的时间!在第1章中我就学到了一条我准备今天开始使用的新技巧。” 　　Karen Liu，首席程序经理，Microsoft Visual C# 　　“很好地从内行人的角度讲述了Visual Studio IDE！” 　　Lisa Feigenbaum，程序经理，Microsoft Visual Studio语言 　　　　
测试覆盖率
测试的主要评测方法 简介 　　测试的主要评测方法包括覆盖和质量。 　　测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。 　　质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。 覆盖评测 　　覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。 　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。 　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。 　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。 　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。 基于需求的测试覆盖 　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。 　　在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。 　　这些覆盖评测通过以下公式计算： 　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。 基于代码的测试覆盖 　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。 　　基于代码的测试覆盖通过以下公式计算： 质量评测 　　测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。 　　缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。 　　严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。 　　缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。 　　对于缺陷分析，常用的主要缺陷参数有四个： 　　• 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。 　　• 优先级：必须处理和解决缺陷的相对重要性。 　　• 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。 　　• 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。 　　可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。 　　例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测"较差的模块"、"热点"或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。 　　这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。 缺陷报告 　　Rational Unified Process 以三类形式的报告提供缺陷
发帖
研发管理
加入

1243

社区成员

2.8w+

社区内容

软件工程/管理 管理版
社区管理员
  • 研发管理社区
申请成为版主
帖子事件
创建了帖子
2003-09-12 10:21
社区公告
暂无公告