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，测试+重构才是王道。