Designing Qt-Style C++ APIs by Matthias Ettrich
e文全文地址: http://doc.trolltech.com/qq/qq13-apis.html
譯文：設計Qt風格的C++API by Googol Lee
本文是讀書筆記，原文和譯文都比本文精彩，建議選擇閱讀。
評價一片文章是否爛的標準是：你是否看過之后感覺不痛不癢。
一片爛文章的來由通常有兩條，一是文章的爛是客觀存在的，另一個就是看文章的人太麻木，以至于針尖戳背亦難覺痛癢。
這篇文章，釋開了我心頭的數朵疑云，漂浮如下。
1、便利陷阱
原先的困惑：是在默認構造函數或Initialize函數列表中一次性傳入所有的對象運行期間的狀態信息，還是通過修改器逐一設置？
現在的認識：不要再默認構造函數或者是初始化函數的參數列表中過分羅列參數，應用場景的變化會需要更新參數列表進行配合，既晦澀難懂，又不好擴展。通過Setter來設置這些參數，還可以給運行期間的對象內部信息修改帶來便利，很好，很方便。
2、布爾參數陷阱
原先的困惑：原先的接口已經定義好，現在由于一些原因，需要一個bool變量來控制其中一些行為的為與不為，直接加上，很方便。因為同時修改了接口參數列表，心有戚戚焉。這個問題曾經向大田請教過，他慣用的做法是重載接口。
現在的認識：修改接口列表的行為是丑陋的，重載接口暫不討論。較好的做法是添加一個接口，在接口名上添加功能，勝過添加參數。因為給一個已經存在的函數添加一個布爾參數，常常是錯誤的。
3、命名的藝術
原先的困惑：曾經把常用單詞的縮略形式貼到桌面上，日日誦讀，一路寫來，效果不佳。因為時常因為記不得縮寫的確切形式，而采用全寫，精神狀態好，記憶清晰的時候，又用了縮寫。有些縮寫是很不容易用縮寫區分的，比如def，即可以解釋成default，也可以解釋成defination。
現在的認識：除個別沒有歧義的縮寫之外，其他都不要用，比如dialog->dlg, win->windows。
4、給枚舉類型及其值命名
原先的困惑：枚舉是一種特殊的數據類型，他到底是多長8、16或者32位，是通過編譯器設定的。另外命名也令我頭痛，寫成BottomRight又覺得不夠醒目，如果作為成員函數怎么辦呢？eBottomRight嗎？
現在的認識：namespace Qt的定義和Qt::Insensitive的引用足夠醒目，把”標志“類用-Flag做后綴，達意更確切。
5、指針還是引用？
這是一個從學編程就知道的問題，看了諸多文獻，公說公有理，婆說婆有理，誰說誰有理，還是按照原先養成的習慣來吧。
看看手中的模塊，我犯的許多毛病都在Qt3中也找到了的，可見這些毛病是人類的通病了，不需過分自責。
做好的API，測試+重構才是王道。
posted on 2008-03-03 07:59
創建更好的解決方案 閱讀(2042)
評論(6) 編輯 收藏 引用 所屬分類:
C++專欄 、
軟件設計