Designing Qt-Style C++ APIs by Matthias Ettrich 
e文全文地址: http://doc.trolltech.com/qq/qq13-apis.html 
譯文：設(shè)計(jì)Qt風(fēng)格的C++API  by Googol Lee
本文是讀書筆記，原文和譯文都比本文精彩，建議選擇閱讀。

評(píng)價(jià)一片文章是否爛的標(biāo)準(zhǔn)是：你是否看過(guò)之后感覺(jué)不痛不癢。
一片爛文章的來(lái)由通常有兩條，一是文章的爛是客觀存在的，另一個(gè)就是看文章的人太麻木，以至于針尖戳背亦難覺(jué)痛癢。
這篇文章，釋開(kāi)了我心頭的數(shù)朵疑云，漂浮如下。
1、便利陷阱
原先的困惑：是在默認(rèn)構(gòu)造函數(shù)或Initialize函數(shù)列表中一次性傳入所有的對(duì)象運(yùn)行期間的狀態(tài)信息，還是通過(guò)修改器逐一設(shè)置？
現(xiàn)在的認(rèn)識(shí)：不要再默認(rèn)構(gòu)造函數(shù)或者是初始化函數(shù)的參數(shù)列表中過(guò)分羅列參數(shù)，應(yīng)用場(chǎng)景的變化會(huì)需要更新參數(shù)列表進(jìn)行配合，既晦澀難懂，又不好擴(kuò)展。通過(guò)Setter來(lái)設(shè)置這些參數(shù)，還可以給運(yùn)行期間的對(duì)象內(nèi)部信息修改帶來(lái)便利，很好，很方便。
2、布爾參數(shù)陷阱
原先的困惑：原先的接口已經(jīng)定義好，現(xiàn)在由于一些原因，需要一個(gè)bool變量來(lái)控制其中一些行為的為與不為，直接加上，很方便。因?yàn)橥瑫r(shí)修改了接口參數(shù)列表，心有戚戚焉。這個(gè)問(wèn)題曾經(jīng)向大田請(qǐng)教過(guò)，他慣用的做法是重載接口。
現(xiàn)在的認(rèn)識(shí)：修改接口列表的行為是丑陋的，重載接口暫不討論。較好的做法是添加一個(gè)接口，在接口名上添加功能，勝過(guò)添加參數(shù)。因?yàn)榻o一個(gè)已經(jīng)存在的函數(shù)添加一個(gè)布爾參數(shù)，常常是錯(cuò)誤的。
3、命名的藝術(shù)
原先的困惑：曾經(jīng)把常用單詞的縮略形式貼到桌面上，日日誦讀，一路寫來(lái)，效果不佳。因?yàn)闀r(shí)常因?yàn)橛洸坏每s寫的確切形式，而采用全寫，精神狀態(tài)好，記憶清晰的時(shí)候，又用了縮寫。有些縮寫是很不容易用縮寫區(qū)分的，比如def，即可以解釋成default，也可以解釋成defination。
現(xiàn)在的認(rèn)識(shí)：除個(gè)別沒(méi)有歧義的縮寫之外，其他都不要用，比如dialog->dlg, win->windows。
4、給枚舉類型及其值命名
原先的困惑：枚舉是一種特殊的數(shù)據(jù)類型，他到底是多長(zhǎng)8、16或者32位，是通過(guò)編譯器設(shè)定的。另外命名也令我頭痛，寫成BottomRight又覺(jué)得不夠醒目，如果作為成員函數(shù)怎么辦呢？eBottomRight嗎？
現(xiàn)在的認(rèn)識(shí)：namespace Qt的定義和Qt::Insensitive的引用足夠醒目，把”標(biāo)志“類用-Flag做后綴，達(dá)意更確切。
5、指針還是引用？
這是一個(gè)從學(xué)編程就知道的問(wèn)題，看了諸多文獻(xiàn)，公說(shuō)公有理，婆說(shuō)婆有理，誰(shuí)說(shuō)誰(shuí)有理，還是按照原先養(yǎng)成的習(xí)慣來(lái)吧。

看看手中的模塊，我犯的許多毛病都在Qt3中也找到了的，可見(jiàn)這些毛病是人類的通病了，不需過(guò)分自責(zé)。

做好的API，測(cè)試+重構(gòu)才是王道。