第1招：看网上评论
　　首先，上一些权威的图书网站，看看大伙儿的评价如何（要相信群众的眼睛是雪亮的）。对于英文书籍，我一般上亚马逊网站去看看；中文书籍则上豆瓣网。这两个网站都提供星级评分，一般>=4星的评级都不差。（此招数对于正在逛书店的不一定适用，除非你随身带了上网的东东）

　　第2招：看作者
　　书籍作者的重要性无需多说。根据二八原理，大部分的好书都是少数优秀作者写出来的。如果作者是该领域的技术大牛或者知名评论家，那么该书的质量一般不会太差。不过要用这招，你首先得对这本书所在的领域有一定的了解，知道哪些人属于该领域的大牛。

　　第3招：看出版信息
　　出版信息里面，主要看出版社、出版时间。好的出版社出的书，总体水平还过得去，不至于太滥，排版印刷错误也较少。
　　出版时间的重要性得看具体的领域。比如某些领域（算法、软件工程等）的书，对于时间不敏感。即使年代久远也没有过时（比如人月神话发表于1975年）。而另一些领域（涉及具体的语言、软件、操作系统）则需要与时俱进，3-5年之前出版的书可能就已经过时了。
　　如果是纸版书，还可以看看再版次数和印数。这两个指标一般和销量成正比。不过也不排除少数阳春白雪的好书，销量很低。因此这两个指标仅供参考。

　　第4招：看目录
　　看完出版信息后，就可以大致看看目录。从目录可以了解到很多信息。好书的目录一般层次分明、条理清晰。滥书则反之。
　　看目录还可以在最短时间内大致了解该书的深浅以及内容的分布（看每一章占了多少页），从而判断这本书能否适合自己。
　　比如，我曾经看过一本国内作者写的《面向对象Java编程》。打开目录扫了一下，整本书都是讲Java语法，只在其中一章提到了OO，页数占全书比例不到10%（我强烈怀疑作者是否直接拿了SUN的Java语言规范汉化了一下，就拿去出版了）。

　　第5招：抽查几页
　　最后，可以挑书中的某个小节看一下。看看作者的文笔是否流畅、生动。如果是翻译的书，则还要注意一下翻译的水平如何。翻译的书的质量同时取决于作者和译者的水平，任何一个不行，整本书就好不到哪里去。
　　早些年学习MFC的时候，曾看过一本翻译的书，把MFC的“doc/view”翻译成"文档查看"，当场厥倒。所以有条件看看原著（你的洋文够牛）的同学就尽量看原著，免得被差劲的译者带到沟里。

　　IT技术书籍的选择就暂且聊到这里。以后，我打算不定期地推荐一些经典的书籍给列位看官。和书评相关的帖子都在这里。
--------------------------------------------------------------------------------
追求原创，欢迎转载。
转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址：
http://program-think.blogspot.com/2009/01/choose-it-book.html

　　★第一步：WHAT
　　所谓的“WHAT”，就是搞清楚某个东东是什么？有什么用？有什么语法？有什么功能特性？......
　　举例如下：
　　对于学习语言（比如C++、Java、Python），大部分人都能够掌握基本的语法和标准库，然后用它写一些小程序（诸如二分查找、冒泡排序、简单文件操作等）。
　　对于学习类库（比如JDBC类库），大部分Java程序员都能明白JDBC主要包含哪些类，也能够用JDBC进行简单的数据库查询和增删改操作。
　　由于这个步骤是最基本的，假如你连这都做不到（可能你的理解力不够好），也别在IT界混了。
　　但是光会What是不够的。仅仅停留在这个步骤，导致了很多程序员只知其然，不知其所以然。这就是目前大部分开发人员的现状。

　　★第二步：HOW
　　所谓的“HOW”，就是搞清楚某个东西内部是如何运作的？实现机制如何？等一系列相关问题。
　　举例如下：
　　假如你在学习C++语言，你是否搞明白函数传参数的实现机制？虚函数是如何实现？抛出异常时的栈回退是怎么回事？......
　　假如你在学习Java语言，你是否搞清楚GC如何实现？反射是如何实现？......
　　假如你在学习JDBC库，你是否清楚JDBC Driver的4种类型？不同游标类型的实现机制？事务的机制？......
　　在这个阶段，你必须多想想类似这些问题。然后通过各种途径（参见“关于自学能力”的几个方法），把问题彻底搞清楚。自然而然，你的提高就会比较明显。而且如果碰到一些深层次的问题（比如性能优化），也就知道该如何去解决。
　　完成这个阶段之后，你基本上就属于该技术领域最优秀的20%的人（根据二八原理，80%的人不会去思考HOW的问题）。

　　★第三步：WHY
　　一般来说，只有你把HOW的问题想清楚，才开始考虑步骤WHY。
　　所谓的“WHY”，就是搞清楚某个东西为什么设计成这样？为什么不是另外的样子？这样的设计有什么讲究？
　　说实在的，善于问“为什么”有一定的天赋成分？好像某个科学大牛曾经说过“提出问题有时候比解决问题更难”。一般来说，只有当你深刻理解了某个东西，才能够针对这个东东的设计问出一些问题。所以，我前面强调过，要先把HOW的问题搞清楚，再来考虑WHY的问题。
　　举例如下：
　　对于C++语言：为什么C++没有类似Java的finally关键字？为什么C++当初没有考虑GC？......
　　对于Java语言：为什么Java没有类似C++的类析构函数？为什么Java要同时提供String和StringBuffer两个似乎冗余的类？......
　　对于Python语言：为什么Python不提供类似C++/Java的访问控制机制？......
　　如果你能够自己问出诸如上述的“为什么”问题，并且能够通过各种途径找到解答，那你基本上已经吃透这个技术了，并且你已经有可能自己去设计一个类似的玩意儿了。到这时，你已经踏上了通向技术高手的康庄大道。

　　由于本博客偏重IT方面，所以今天举的这些例子多半都是IT相关的，但是这个三部曲在IT以外的行业/领域其实也能适用，就看读者自己的领悟了。

转载必须包含本声明、保持本文完整。并以超链接形式注明作者编程随想和本文原始地址：
http://program-think.blogspot.com/2009/02/study-technology-in-three-steps.html

单例模式也称为单件模式、单子模式。使用单例模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。有很多地方需要这样的功能模块，如系统的日志输出等。

单例模式有许多种实现方法，在C++中，甚至可以直接用一个全局变量做到这一点，但这样的代码显得很不优雅。《设计模式》一书中给出了一种很不错的实现，定义一个单例类，使用类的私有静态指针变量指向类的唯一实例，并用一个公有静态方法获取该实例。如下面的类定义：

class CSingleton:
{
// 其它成员
public:
   static CSingleton * GetInstance()
   {
      if (m_pInstance == NULL)
            m_pInstance = new CSingleton(); 
      return m_pInstance; 
   }

private:
   CSingleton(){}; 
   static CSingleton * m_pInstance;
}
单例类CSingleton有以下特征：
Ø 它有一个指唯一实例的静态指针m_pInstance，并且是私有的。
Ø 它有一个公有的函数，可以获取这个唯一的实例，并在需要的时候创建该实例。
Ø 它的构造函数是私有的，这样就不能从别处创建该类的实例。

大多时候，这样的实现都不会出现问题。有经验的读者可能会问，m_pInstance指向的空间什么时候释放呢？更严重的问题是，这个实例的析构操作什么时候执行？

如果在类的析构行为中有必须的操作，比如关闭文件，释放外部资源，那么上面所示的代码无法实现这个要求。我们需要一种方法，正常地删除该实例。

可以在程序结束时调用GetInstance并对返回的指针调用delete操作。这样做可以实现功能，但是不仅很丑陋，而且容易出错。因为这样的附加代码很容易被忘记，而且也很难保证在delete之后，没有代码再调用GetInstance函数。

一个妥善的方法是让这个类自己知道在合适的时候把自己删除。或者说把删除自己的操作挂在系统中的某个合适的点上，使其在恰当的时候自动被执行。

我们知道，程序在结束的时候，系统会自动析构所有的全局变量。事实上，系统也会析构所有的类的静态成员变量，就像这些静态成员也是全局变量一样。利用这个特征，我们可以在单例类中定义一个这样的静态成员变量，而它的唯一工作就是在析构函数中删除单例类的实例。如下面的代码中的CGarbo类（Garbo意为垃圾工人）：
class CSingleton:
{
// 其它成员
public:
   static CSingleton * GetInstance()
   {。。。}
private:
   CSingleton(){}; 
   static CSingleton * m_pInstance;

   class CGarbo // 它的唯一工作就是在析构函数中删除CSingleton的实例
   {
   public:
   ~CGarbo()
   {
      if (CSingleton::m_pInstance)
         delete CSingleton::m_pInstance; 
      }
   };

   static CGarbo Garbo; // 定义一个静态成员，在程序结束时，系统会调用它的析构函数
}

类CGarbo被定义为CSingleton的私有内嵌类，以防该类被在其它地方滥用。

在程序运行结束时，系统会调用CSingleton的静态成员Garbo的析构函数，该析构函数会删除单例的唯一实例。

使用这种方法释放单例对象有以下特征：
Ø 在单例类内部定义专有的嵌套类。
Ø 在单例类内定义私有的专门用于释放的静态成员。
Ø 利用程序在结束时析构全局变量的特性，选择最终的释放时机。
Ø 使用单例的代码不需要任何操作，不必关心对象的释放。