应用MFC开发高级应用程序

苟建兵 清华大学热能系(北京，100084)

       四、使用DDE服务  五、使用3D控制  六、使用自定义消息  

       七、使用不带文挡-视结构的MFC应用  八、MFC应用的人工优化

[摘要]：目前在Windows下开发应用程序的工具虽然很多，但是C/C++作为一种非常成
熟和高效的开发语言在大型复杂项目的开发中仍然得到了广泛应用。为了减轻程序
开发负担，提高开发效率，各种流行的C++都提供了类库，本文就是针对如何在
Visual C++环境中使用MFC类库来开发高级程序所需要解决的一些问题进行了的探
讨，重点讨论了利用MFC开发单文档多视应用程序和DDE应用程序的方法。

一、使用C/C++
随着Windows系列操作系统的日益普遍，传统的基于DOS编程逐渐转向Windows下编程
已经成为必然趋势。目前在Windows下开发应用程序的工具很多，典型的如Borland
C++、Visual C++、Visual Baisic以及Delphi等等。每种开发工具都各有其特点，
一般来讲用户可以根据自己的使用习惯和开发项目的性质来选择具体的开发语言。

Visual Basic是一个被软件界称之为划时代的革新产品，该软件改变了人们开发
Windows程序的方式，它采用交互式的可视化操作，使得人们开发Windows程序的每
一过程都有直观形象的反馈，从而加速整个开发进程。Visual Basic使得Windows程
序设计人员不再只依赖于复杂的SDK编程，使得开发Windows程序非常容易，可以
说，用户学习并使用VB来开发Windows应用的时间是最短的。Visual Basic版本几经
演变，目前已经发展到5.0。在4.0版本中，由于完全使用了面向对象的编程概念，
同时具有Windows 3.1和Windows 95下的版本，因而使得其开发复杂程序的功能逐渐
增强。VB5.0则抛弃了Windows 3.x的用户，只能在32位Windows中使用，据悉，该版
本吸收了Delphi的成功策略，引入了本地代码(Native Code)编译器，从而使得程序
执行速度大大加快，克服了以往版本由于执行文件采用P-Code代码而导致运行速度
慢的特点，根据微软的声明，该版本的采用本地代码编译后得到的应用程序在某些
情况下执行速度较以往提高了10~20倍，执行速度可以直逼与采用Visual C++编写的
应用，而应用开发速度则是VB的强项，因此Visual Basic 5.0非常具有竞争性。目
前Visual Basic非常广泛地用于开发各种Windows程序，如数据库前端应用程序和多
媒体应用等。但是，在作者看来，采用VB也有一定的缺点，原因有以下几点：
1. Visual Basic来源于Basic语言，虽然经过微软的不断增强，但是仍然缺乏非常
灵活的数据类型和编程策略，因而在开发一些项目必须的复杂数据结构遇到麻烦，
如链表、图和二叉树等等。由于在中大型项目开发后期，开发工作不再以界面为
主，而是在算法设计和底层软硬件工作，这就使VB开发项目的后期工作量大幅度增
加，为了达到项目要求，经常需要再转向C/C++开发一些专用的动态连接库来解决问
题。
2. Visual Basic运行速度慢，前文讲过，采用P-Code代码虽然执行文件很小，但是
在运行时需要解释执行，并且，它的运行必须有对应的VBRUN.DLL和所使用的VBX或
者OCX支持。对于浮点操作密集或者循环嵌套很多的应用来说，VB没有采取特别的优
化，因而执行速度远不如用C/C++和Fortran开发的应用速度快。VB 5.0虽然通过引
入本地代码编译器大大弥补了这个缺陷，但是由于其只能运行于32位Windows环境因
而在16位Windows上速度问题仍然得不到解决。虽然目前转向32位Windows的趋势非
常强劲，但是不容忽视由于硬件的限制或者使用习惯等诸多原因，还有许多用户仍
然在16位Windows上工作。在计算机十分普及的美国，96年使用16位Windows的用户
仍然超过了使用32位Windows的用户，任何进行系统软件设计的人员都应该照顾到这
些仍然使用16位Windows的用户。
3. VB不能灵活地使用系统资源。熟悉Windows编程的人都知道，如果要直接访问硬
件或者要编写对系统进行有效访问的应用程序，没有Windows API函数的帮助则非常
困难，但是令VB程序员失望的是，API函数是用C语言和汇编语言实现的，是为C编程
准备的，如果要在VB里面使用这些上千个API函数则比较麻烦，特别是，如果设计人
员不懂C语言则尤其困难。由于API函数的复杂性，而其本身不是为了方便VB编程而
提供的，因此在VB里面调用API函数需要一定的技巧，这些技巧足够用一本很厚的书
来表述。VB程序员可以从书店里找到好多本类似的书籍。可以说，任何一个VB程序
员发展到一定阶段都需要与众多的API函数打交道。另外，由于VB不支持端口操作，
因此，如果要编写类似数据采集等需要与硬件交互的程序则需要求救于C/C++语言。

4. Visual Basic项目分发和管理困难，其原因同上讲的，VB应用的运行不能脱离VB
的运行库和所使用的控件，因此，如果开发人员要将VB应用分发给用户那么一定要
带上VB的运行库和所使用的控件，并且要保证正确安装，这就导致即使一个非常简
单的应用也需要附带大量其它相关支撑库程序，对于VB 4.0及更高版本，由于大量
的使用了OLE控件（在VB中称为OCX），其安装更为复杂。
Delphi软件是国际宝兰公司(Borland)的得意之作，也是备受软件界推崇，与VB一
样，它完全是一个交互式的可视化开发平台，支持Client/Server应用程序的开发，
其最新版本2.0可以开发Windows 3.x、Windows 95和Windows NT的应用程
序。Delphi开发速度也非常快，与VB相比，由于具有本地代码编译器因此它产生的
可执行文件执行速度大大加快。Delphi软件是一个非常有竞争力的软件，采用的是
面向对象的Object pascal语言，支持硬件操作和API调用。但是由于采用的编程语
言为Pascal，这种语言并不非常流行，许多程序设计人员完全不熟悉这种语言，因
此极大地限制了该软件的使用，如果宝兰公司能够将Delphi软件提供的RAD开发机制
引入到其Borland C++中，则可能会形成一个非常成功的产品（目前该版本已经推
出，即C++ Builder，笔者注）。
VB和Delphi引入的可视化开发方法还有一个共同的缺点就是各个版本之间的兼容问
题。一般来讲，采用这些可视化开发工具开发的应用程序在移植到高版本时不会遇
到太大困难，但是一旦往相反方向移植则困难重重，有时甚至不可能。C/C++语言则
不具有这种局限性，各个版本之间的相互移植并不困难，高版本往低版本移植一般
只需重建工程文件即可大功告成。
综上所述，根据作者的观点，如果要开发一个大型复杂的应用程序首选的还是
C/C++，特别是在16位Windows下。虽然这会使前期工作增加，但是在项目的中后期
将逐渐会领略到其优越性和开发效率，其灵活高效的执行代码适合于对速度和应用
程序之间的协同性要求很高的场合。纯粹基于Windows SDK来开发Windows程序是一
项艰巨的工程，值得庆幸的是目前各种流行的C/C++开发工具都提供了类库开发框架
来简化整个开发过程而又不失其固有的灵活高效性，不同的开发语言所提供的类库
开发框架不同，如Borland C++提供的OWL(Object Windows Library)和 Visual C++
提供的MFC(Microsoft Fundmental Class)，这两种类库都封装了大量的Windows
API和Windows的开发元素而使得开发任务简化，两种类库各有其优点，据作者掌握
的资料，采用MFC编写的应用程序执行代码更小，执行速度也更快，这大概是因为该
软件的开发者是开发Windows操作系统的Microsoft公司的缘故吧，现在MFC正逐渐成
为Windows下的类库开发标准，正被越来越多的其它C/C++编译工具所支持，如
Watcom C++。使用MC类库同时配合Visual C++提供的AppWizard、ClassWizard和
AppStudio可以大幅度提高开发效率。笔者在工作中积累了一些MFC的使用经验现在
提出来供大家参考，希望对广大同行有所帮助，尤其是那些仍然致力于16位Windows
编程的程序员。本文使用的Visual C++ 1.51编译器，但是其方法同样适用于其它
VC++版本，包括Visual C++ 4.x。
二、MFC编程综述
采用MFC开发Windows程序之所以能够大幅度提高开发速度和效率主要是因为MFC在类
层次封装了大量Windows SDK函数和典型Windows应用的缺省处理，这样，用户只需
要较少的编程就可以实现自己的开发任务。如果在MFC基础上再配合Visual C++提供
的AppWizard、ClassWizard和AppStudio工具那么更可以大幅度加快开发进程。MFC
提供大量的基类供程序员使用，常见的如CWinApp类、CFrameWnd类、CMDIFrameWnd
类、CMDIChildWnd类、CView类、CDC类和CDocument类等等。通过从这些基类中派生
出用户自己的类，然后重载特殊的几个函数就可以生成一个独立的应用程序。可以
说，采用MFC编写Windows应用程序是非常方便的，虽然其学习过程并不简单，但是
其提供的灵活高效性足以使任何Windows程序开发人员为之付出努力。如果用户不曾
使用过MFC，那么用户可以通过附录中所列的参考书去学习MFC的强大功能。
采用MFC应用框架产生的应用程序使用了标准化的结构，因而使得采用MFC编写的程
序的在不同平台上的移植变得非常容易，事实上，MFC的16位和32位版本之间差别很
小。MFC提供的标准化结构是经过众多专家分析调研后总结编写出来的，一般情况下
可以满足绝大多数用户的要求，但有时用户也可以通过重载一些函数来修改其缺省
的风格从而实现自己特有的风格，如自定义应用图表和灰色背景等。在MFC提供的文
档视结构中，文档、视和资源之间的联系是通过定义文档模板来实现的，如：
m_pSimuTemplate = new CMultiDocTemplate(
IDR_SIMUTYPE,
RUNTIME_CLASS(CSimuDoc),
RUNTIME_CLASS(CMyChild), // Derived MDI child frame
RUNTIME_CLASS(CSimuView));
上中第一项IDR_SIMUTYPE就包括了视口的菜单，加速键和图表等资源，如果用户使
用AppWizard来产生的应用基本框架，那么其也同时产生了缺省的图标，如果用户不
满意缺省图标（实际上用户很少满足于缺省图标），只需要将缺省图标删除，然后
编辑或者直接引入一个新的图标，在存储这一图标时只需要使用与被删除图标同样
的ID即可实现替代。
熟悉Windows程序开发的人都知道，在Windows上通过使用灰色背景可以增强应用程
序的视觉效果，曾有人戏称，灰色是图形界面永恒的颜色。使用MFC产生的应用程序
的背景缺省为白色，如果用户希望改变成灰色或者其它颜色，那就需要使用单独处
理，解决的办法很多，如在每次视口的OnPaint()事件中采用灰色刷子人为填充背
景，但是这不是最好的办法。笔者发现最好的办法就是采用AfxRegisterWndClass()
函数注册一个使用灰色背景刷的新的窗口类，这需要重载PreCreateWindow()函数来
实现这一点，如下程序代码片段所示：
BOOL CSimuView::PreCreateWindow(CREATESTRUCT& cs)
{
HBRUSH hbkbrush=CreateSolidBrush(RGB(192,192,192));//创建灰色背景刷
LPCSTR lpMyOwnClass=AfxRegisterWndClass(CS_HREDRAW
|CS_VREDRAW|CS_OWNDC,0,hbkbrush);//注册新类
cs.lpszClass=lpMyOwnClass;//修改缺省的类风格
return TRUE;
}
采用这种方法速度最快，也最省力。同时，还可以在PreCreateWindow()函数定义所
希望的任何窗口风格，如窗口大小，光标式样等。
三、使用单文档-多视结构
如果用户使用过MFC进行编程，那么就会发现借助于AppWizard基于MFC无论编写SDI
(单文档界面)还是编写MDI(多文档界面)都是十分方便的。MDI应用程序目前使用越
来越普遍，人们熟悉的Microsoft公司的Office系列产品以及Visual系列产品都是典
型的多文档应用程序。这种多文档界面具有多窗口的特点，因而人们可以在一个程
序中使用多个子窗口来实现不同数据的浏览查看。如果用户要实现在MDI各个窗口之
间针对同一数据进行不同的可视化就是一件比较麻烦的事情。值得庆幸的是，MFC提
供的文档-视结构大大简化了这一工作。文档-视结构通过将数据从用户对数据的观
察中分离出来，从而方便实现多视，亦即多个视口针对同一数据，如果一个视口中
数据发生改变，那么其它相关视口中的内容也会随之发生改变以反映数据的变化。
SDI和MDI这两种Windows标准应用程序框架并不是总能满足用户的需要，就作者的工
作而言，就特别需要一种被称为单文档多视的应用程序，英文可以缩写为SDMV。通
过SDMV应用我们可以利用文档类来统一管理应用程序的所有数据，同时需要采用多
窗口以多种方式来可视化这些的数据，如棒图，趋势图和参数列表，从而方便用户
从不同角度来观察数据。MDI虽然具有多窗口的特点，但是其为多文档，即通常情况
下，一个视口对应一个文档，视口+文档便构成一个子窗口。在各个子窗口之间数据
相互独立，如果要保持数据同步更新就需要采用特殊的技术了，采用这种方式既费
时又费力。通过笔者的实践发现，利用MFC本身提供的多视概念通过适当改造MDI窗
口应用程序就可以实现上述SDMV结构。
所谓SDMV应用程序本质上仍然是一个MDI应用程序，只是在程序中我们人为控制使其
只能生成一个文档类，这个文档在第一个视口创建时创建，注意，这里并不需要限
制各个视口的创建先后顺序。此后与MDI窗口固有特性不同的是，所有新创建的子窗
口都不再创建独立文档，而是把该新视口直接连接到已有的文档对象上，这样就使
其成为单文档多视的结构，所有相关数据都存储在文档对象中，一旦文挡中数据发
生改变，通过UpdateAllViews()函数通知所有相关视口，各个视口就可以在
OnUpdate()中相应数据的变化。这种响应机制如下图所示:

图 1 文档-视结构数据更新机制
由于MDI本质上并不是为这种单文档多视机制服务的，因而在实际应用时需要解决一
些问题。
1、窗口标题问题
窗口标题本来不应该成为问题，缺省情况下MDI窗口通过在文档模板中提供的资源ID
所提供的对应字符串来确定窗口标题。但是对于SDMV应用，由于各个视口实质上是
对应于同一个文挡，因此每个视口都具有相同标题，只不过增加了一个数据用于指
示这是第几个视口。如果在各个视口中指明具体的窗口名字，那么由不同的视口启
动创建文档产生的窗口标题就不同，这个名字会影响到后继视口。为了作到不同类
型的视口如棒图视口和曲线视口具有不同的标题，这就需要一定的技术处理。根据
笔者的摸索发现可以采用如下步骤实现：
首先在从标准的MDI子窗口基类CMDIChildWnd派生一个自己的子窗口类，姑且命名为
CMyChild，然后在其成员变量中增加一个CString型变量用以存储当前窗口标题：
CString winTitle;
然后在不同的视口创建过程中通过获取父窗口指针按自己的意愿对上述变量进行赋
值，程序片段如下：
pChild=(CMyChild*)GetParent();
pChild->winTitle="棒图显示窗口";
最后在CMyChild派生类中重载CMDIChildWnd基类中的OnUpdateFrameTitle()函数来
强制实现窗口标题的个性化，这一函数在各种类库手册上和联机帮助中都没有，但
的确有这样一个具有保护属性的函数用来实现窗口标题的更新操作，这可以从MFC类
库的源代码中找到该函数的实现。重载后的源代码如下：
void CMyChild::OnUpdateFrameTitle(BOOL bAddToTitle)
{
// update our parent window first
GetMDIFrame()->OnUpdateFrameTitle(bAddToTitle);

if ((GetStyle() & FWS_ADDTOTITLE) == 0)
return; // leave child window alone!

CDocument* pDocument = GetActiveDocument();
if (bAddToTitle && pDocument != NULL)
{
char szOld[256];
GetWindowText(szOld, sizeof(szOld));
char szText[256];

lstrcpy(szText,winTitle); //Modified by author!
if (m_nWindow > 0)
wsprintf(szText + lstrlen(szText), ":%d", m_nWindow);

// set title if changed, but don't remove completely
if (lstrcmp(szText, szOld) != 0)
SetWindowText(szText);
}
}
2、如何创建SDMV应用
如何创建SDMV应用比较麻烦，下面通过举例来具体说明。该例子假设用户需要建棒
图类型和曲线形式的两种视口，假设用户已经利用CView基类派生并且实现了这两个
类，分别对应于CMyChart和CMyTraceView两个类。
1) 在应用类（从CWinApp派生出来的类）的头文件中加入下列变量和函数原型说
明：
CMultiDocTemplate* m_pMyTraceTemplate;
CMultiDocTemplate* m_pMyChartTemplate;
int ExitInstance();
2) 在应用类的InitInstance成员函数中删除对AddDocTemplate函数的调用和
OpenFileNew()语句，并且加入如下代码：
m_pMyTraceTemplate = new CMultiDocTemplate(
IDR_MYTRACEVIEW,
RUNTIME_CLASS(CSimuDoc),
RUNTIME_CLASS(CMyChild), // Derived MDI child frame
RUNTIME_CLASS(CMyTraceView));

m_pMyChartTemplate = new CMultiDocTemplate(
IDR_MYCHART,
RUNTIME_CLASS(CSimuDoc),
RUNTIME_CLASS(CMyChild), // Derived MDI child frame
RUNTIME_CLASS(CMyChart));
3) 实现ExitInstance()函数，在其中删除所用的两个辅助模板：
int CTestApp::ExitInstance()
{
if(m_pMyChartTemplate) delete m_pMyChartTemplate;
if(m_pMyTraceTemplate) delete m_pMyTraceTemplate;
return TRUE;
}
4) 在菜单资源中去掉File菜单中的New和Open项，加入New Chart View和New
Trace View两项，在对应的菜单命令中实现如下：
void CMainFrame::OnNewMychart()
{
// TODO: Add your command handler code here
OnNewView(((CSimuApp*)AfxGetApp())->m_pMyChartTemplate);
}
void CMainFrame::OnNewMyTrace()
{
// TODO: Add your command handler code here
OnNewView(((CSimuApp*)AfxGetApp())->m_pMyTraceTemplate);
}
上中OnNewView的实现如下：
BOOL CMainFrame::OnNewView(CMultiDocTemplate* pDocTemplate)
{
CMDIChildWnd* pActiveChild = MDIGetActive();
CDocument* pDocument;
if (pActiveChild == NULL ||
(pDocument = pActiveChild->GetActiveDocument()) == NULL)
{
TRACE0("Now New the specify view\n");
ASSERT(pDocTemplate != NULL);
ASSERT(pDocTemplate->IsKindOf(RUNTIME_CLASS(CDocTemplate)));
pDocTemplate->OpenDocumentFile(NULL);
return TRUE;
}

// otherwise we have a new frame to the same document!
CMultiDocTemplate* pTemplate = pDocTemplate;
ASSERT_VALID(pTemplate);
CFrameWnd* pFrame = pTemplate->CreateNewFrame(pDocument, pActiveChild);
if (pFrame == NULL)
{
TRACE0("Warning: failed to create new frame\n");
return FALSE; // command failed
}
pTemplate->InitialUpdateFrame(pFrame, pDocument);
return TRUE;
}
OnNewView是整个SDMV应用的核心组成，它的任务是创建一个新的指定类型的视口，
它首先判断是否有活动视口存在，文档是否已经创建，正常情况下活动视口存在则
表明文档存在，如果不存在则利用所指定的文档模板创建一个新的活动视口，否则
则只创建视口，同时将其连接到已存在的文档对象上。
通过以上步骤就可以实现SDMV应用，在其后的具体应用中利用文档对象的
UpdateAllViews()函数和视口的OnUpdate()函数就可以很好的工作了。
四、使用DDE服务
Windows 3.x是一个分时多任务操作环境，在此环境下，多个应用程序可以并发地执
行。为了在并发执行的多个任务之间共享数据和资源，Windows 提供了几种机制，
主要是通过剪贴板(Clipboard)和动态数据交换(Dynamic Data Exchange)。前者对
于用户需要直接参与的数据交换来说，是一个非常方便的工具，但是如果希望数据
交换自动进行时就必须依靠DDE技术了。编写DDE应用的技术也发展了好几代，从最
初的基于消息的DDE到基于DDEML(动态数据交换管理库)，再到现在流行的OLE技
术。DDE技术的发展使得程序开发人员编写DDE应用更为简洁。从发展趋势来看，基
于OLE的数据交换是最好的，它特别符合当今软件领域的客户-服务器机制
(Client-Server)。为适应多平台和Internet的需要，在OLE基础上微软又开发了
ActiveX技术。但是不容忽视的是，基于传统的DDE数据交换也自有它的应用空间，
使用仍然广泛。目前在Windows 3.x下，基于OLE的远程数据交换还很不成熟，但是
在WFW(Windows for Workgroup)下基于网络动态数据交换的技术却很成熟，目前也
应用非常普遍。关于DDE应用的开发和NetDDE的应用可以参看附录7。
1、回调函数的处理
由于DDEML机制需要使用回调函数，因此使用DDEML的关键是解决在MFC编程体系中回
调函数的使用。回调函数(Callback function)大量用于Windows的系统服务，通过
它，程序员可以安装设备驱动程序和消息过滤系统，以控制Windows的有效使用。
许多程序员都发现，利用MFC或者其它的C++应用编写回调函数是非常麻烦的，其根
本原因是回调函数是基于C编程的Windows SDK的技术，不是针对C++的，程序员可以
将一个C函数直接作为回调函数，但是如果试图直接使用C++的成员函数作为回调函
数将发生错误，甚至编译就不能通过。通过查询资料发现，其错误是普通的C++成员
函数都隐含了一个传递函数作为参数，亦即“this”指针，C++通过传递一个指向自
身的指针给其成员函数从而实现程序函数可以访问C++的数据成员。这也可以理解为
什么C++类的多个实例可以共享成员函数但是确有不同的数据成员。由于this指针的
作用，使得将一个CALLBACK型的成员函数作为回调函数安装时就会因为隐含的this
指针使得函数参数个数不匹配，从而导致回调函数安装失败。要解决这一问题的关
键就是不让this指针起作用，通过采用以下两种典型技术可以解决在C++中使用回调
函数所遇到的问题。这种方法具有通用性，适合于任何C++。
1. 不使用成员函数，直接使用普通C函数，为了实现在C函数中可以访问类的成员变
量，可以使用友元操作符(friend)，在C++中将该C函数说明为类的友元即可。这种
处理机制与普通的C编程中使用回调函数一样。
2. 使用静态成员函数，静态成员函数不使用this指针作为隐含参数，这样就可以作
为回调函数了。静态成员函数具有两大特点：其一，可以在没有类实例的情况下使
用；其二，只能访问静态成员变量和静态成员函数，不能访问非静态成员变量和非
静态成员函数。由于在C++中使用类成员函数作为回调函数的目的就是为了访问所有
的成员变量和成员函数，如果作不到这一点将不具有实际意义。解决的办法也很简
单，就是使用一个静态类指针作为类成员，通过在类创建时初始化该静态指针，如
pThis=this，然后在回调函数中通过该静态指针就可以访问所有成员变量和成员函
数了。这种处理办法适用于只有一个类实例的情况，因为多个类实例将共享静态类
成员和静态成员函数，这就导致静态指针指向最后创建的类实例。为了避免这种情
况，可以使用回调函数的一个参数来传递this指针，从而实现数据成员共享。这种
方法稍稍麻烦，这里就不再赘述。
2、在MFC中使用DDEML
对于典型的MFC应用程序，主框架窗口类(CMainFrame)只有一个实例，因此可以使用
静态成员函数作为回调函数，从而实现DDE机制。具体的代码片段如下：
(1) 在CMainFrame类中声明如下静态成员：
static CMainFrame* pThis;
static DWORD idInst;
static HDDEDATA CALLBACK EXPORT DdeCallback(UINT,UINT,HCONV,HSZ,HSZ, HDDEDATA,DWORD,DWORD);
(2) 在类的创建代码(OnCreate())中作如下说明：
pThis=this;
lpDdeCallback=MakeProcInstance((FARPROC)DdeCallback,hInstance);
if(DdeInitialize(&idInst,(PFNCALLBACK)lpDdeCallback,CBF_FAIL_EXECUTES
|CBF_SKIP_REGISTRATIONS|CBF_SKIP_UNREGISTRATIONS,0L))
{
AfxMessageBox("不能初始化DDE服务","错误");
DestroyWindow();
}
(3) 回调函数实现如下：
HDDEDATA FAR PASCAL _export CMainFrame::DdeCallback(UINT iType,UINT iFmt, HCONV hConv,HSZ hsz1,HSZ hsz2,HDDEDATA hData,DWORD dwData1,DWORD dwData2)
{
char szBuffer[16];
int i;

switch(iType)
{
case XTYP_CONNECT: //hsz1=topiv, hsz2=service
return (HDDEDATA)TRUE;//TRUE;
case XTYP_ADVSTART: //hsz1=topic, hsz2=item
case XTYP_REQUEST:
case XTYP_ADVREQ:
case XTYP_POKE: //hsz1=Topic, hsz2=item, hData=data
case XTYP_ADVSTOP:
return NULL;
}
}
3、避免变量类型冲突
如果在MFC应用直接使用DDEML服务，那么该MFC应用在编译时将会遇到变量类型HSZ
重复定义错误。经过追踪发现，错误在于在DDEML.H对HSZ作了如下定义：
DECLARE_HANDLE32(HSZ);
而在AFXEXT.H(通过stdafx.h引入)中对HSZ又作了如下说明：
typedef BPSTR FAR* HSZ; // Long handle to a string
两个定义一个为32位整数，一个为BASIC字符串指针，当然会发生编译器不能作变量
类型转换的错误。实际上，将HSZ声明为BASIC字符串指针主要用于在MFC应用中使用
VBX控制。要改正这一错误，就必须保证不要在同一个代码模块中使用DDEML和VBX支
持，通过将使用DDEML和VBX的代码分开，并在使用DDEML代码的模块中最开头定义如
下编译器宏就可以解决上述问题：
#define NO_VBX_SUPPORT
五、使用3D控制
毫无疑问，3D控制的使用可以显著提高Windows应用程序的界面友好性，目前，许多
流行的Windows应用程序都使用了3D控制，典型的如Microsoft公司的Office系列软
件，而且，在Windows 95和Windows NT 4.0中，3D控制更是作为操作系统的一部分
直接提供，这意味着在其上运行的软件不需要作任何特殊处理，就具有3D界面效
果，但是，很遗憾的是，在Windows 3.x中，除了命令按钮控制使用3D控制以外，其
余所有的控制，如编辑框，列表框，检查框等都只使用2D控制，要想使用3D控制，
程序设计人员就必须在自己的程序中作一定的修改，考虑到目前3D效果的流行，这
点努力是值得的。
为了支持3D效果，Microsoft公司提供了一个专门用于3D控制的动态连接库，即
CTL3D.DLL，但是在其Visual C++中却没有如何使用3D控制的讨论，并且，Visual
C++也不直接支持3D编码，因为它不包括使用3D控制所必须的头文件。但是，这并不
意味着在Visual C++中不能使用3D控制，只不过用户需要从其它地方获取技术支持
罢了。由于使用的是动态连接库机制，因此，任何其它语言提供的3D头文件和
CTL3D.DLL的输入库都是可用的。作者使用的就是Borland公司的Borland C++中提供
的CTL3D.H和CTL3D.LIB。在C/C++中使用3D控制的方法也有很多种，在这里，为节约
篇幅，只讨论与本文相关的主题，即使用MFC编程时如何使用3D控制。
在MFC的所有对话框中使用3D控制可以遵循如下步骤：
1. 在CWinApp::InitInstance函数中调用Ctl3dRegister和Ctl3dAutosubclass函
数：
Ctl3dRegister(AfxGetInstanceHandle());
Ctl3dAutoSubclass(AfxGetInstanceHandle());
值得一提的是，在AppWizard产生的应用框架的CWinApp::InitInstance中有一个函
数调用为SetDialogBkColor，此函数的作用是将所有对话框的背景颜色设置为灰
色，这个功能与3D界面实现相同的功能，可以移去此语句。
由于CTL3D在初始化时读入所有的系统颜色并自己维持，为了使应用程序能够正确反
映系统颜色的变化，MFC应用程序可以在WM_SYSCOLORCHANGE消息中调用
Ctl3dColorChange函数。
2. 在MFC应用程序的CWinApp类中的ExitInstance函数中调用Ctl3dUnregister函
数，以方便Windows对CTL3D库的正确管理。
3. 在MFC应用程序的项目文件中加入CTL3D.LIB（可以用IMPORT.EXE产生）。
使用上述CTL3D的自动子类化的机制可以大大简化使用3D控制，如果这不满足你的要
求，那么你就必须单独在需要使用3D控制的对话框的OnInitDialog()中自行子类化
相关的控制类了，典型的如下代码片断所示：
BOOL CMyDialog::OnInitDialog()
{
Ctl3dSubclassDlgEx(m_hWnd,CTL3D_ALL);
return TRUE;
}
上面讲了在对话框中使用3D效果的办法，如果用户想在非对话框中使用3D控制，典
型的在FormView导出类中使用，可以在导出类的OnInitialUpdate函数中进行适当修
改，修改的大小取决于你是否使用了3D控制的自动子类化机制。如果使用前面提到
的自动子类化方法，那么仅需要在相应的OnInitialUpdate函数中调用
Ctl3dSubclassDlg函数了，如下代码片断所示：
void CMyView::OnInitialUpdate()
{
Ctl3dSubclassDlg(m_hWnd,CTL3D_ALL);
}
否则，则需要修改如下：
void CMyView::OnInitialUpdate()
{
Ctl3dSubclassDlgEx(m_hWnd,CTL3D_ALL);
}
六、使用自定义消息
1、MFC的消息映射机制
Windows是一个典型的消息驱动的操作系统，程序的运行是靠对各种消息的响应来实
现的，这些消息的来源非常广泛，既包括Windows系统本身，如WM_CLOSE、
WM_PAINT、WM_CREATE和WM_TIMER等常用消息，又包括用户菜单选择、键盘加速
键以及工具条和对话框按钮等等，如果应用程序要与其它程序协同工作，那么消息的来
源还包括其它应用程序发送的消息，串行口和并行口等硬件发送的消息等等。总
之，Windows程序的开发是围绕着对众多消息的合理响应和实现来实现程序的各种功
能的。使用过C语言来开发Windows程序的人都知道，在Windows程序的窗口回调函数
中需要安排Switch语句来响应大量的消息，同时由于消息的间断性使得不同的消息
响应之间信息的传递是通过大量的全局变量或者静态数据来实现的。
人们常用的两种类库OWL和MFC都提供了消息映射机制用以加速开发速度，使用者只
需要按规定定义好对应消息的处理函数自身即可，至于实际调用由类库本身所提供
的机制进行，或采用虚函数，或采用消息映射宏。为了有效节约内存，MFC并不大量
采用虚函数机制，而是采用宏来将特定的消息映射到派生类中的响应成员函数。这
种机制不但适用于Windows自身的140条消息，而且适用于菜单命令消息和按钮控制
消息。MFC提供的消息映浠剖欠浅Ｇ看蟮模市碓诶嗟母鞲霾愦紊隙韵⒔?br> 控制，而不简单的局限于消息产生者本身。在应用程序接收到窗口命令时，MFC将按
如下次序寻找相应的消息控制函数：
SDI应用
MDI应用
视口
视口
文档
文档
SDI主框架
MDI子框架
应用
MDI主框架

应用
大多数应用对每一个命令通常都只有一个特定的命令控制函数，而这个命令控制函
数也只属于某一特定的类，但是如果在应用中对同一消息有多个命令控制函数，那
么只有优先级较高的命令控制函数才会被调用。为了简化对常用命令的处理，MFC在
基类中提供并实现了许多消息映射的入口，如打印命令，打印预览命令，退出命令
以及联机帮助命令等，这样在派生类中就继承了所有的基类中的消息映射函数，从
而可以大大简化编程。如果我们要在自己派生类中实现对消息的控制，那么必须在
派生类中加上相应的控制函数和映射入口。
2、使用自己的消息
在程序设计的更深层次，人们常常会发现只依赖于菜单和命令按钮产生的消息是不
够的，常常因为程序运行的逻辑结构和不同视口之间数据的同步而需要使用一些自
定义的消息，这样通过在相应层次上安排消息响应函数就可以实现自己的特殊需
要。比如如果我们要在特定的时间间隔内通知所有数据输出视口重新取得新数据，
要依靠菜单命令和按钮命令实现不够理想，比较理想的解决办法是采用定时器事件
进行特定的计算操作，操作完成后再采用SendMessage发送自己的特定消息，只有当
这一消息得到处理后才会返回主控程序进行下一时间计算。通过在文档层次上安排
对消息的响应取得最新计算数据，而后通过UpdateAllViews()成员函数来通知所有
相关视口更新数据的显示。视口通过重载OnUpdate()成员函数就可以实现特定数据
的更新显示。
如果用户能够熟练使用SendMessage()函数和PostMessage()函数，那么要发送自定
义消息并不难，通常有两种选择，其一是发送WM_COMMAND消息，通过消息的WORD
wParam参数传递用户的命令ID，举例如下：
SendMessage(WM_COMMAND,IDC_GETDATA,0); //MFC主框架发送
然后在文档层次上安排消息映射入口：
ON_COMMAND(IDC_GETDATA, OnGetData)
同时在文档类中实现OnGetData()函数：
void CSimuDoc::OnGetData()
{
TRACE("Now in SimuDoc,From OnGetData\n");
UpdateAllViews(NULL);
}
注意在上中的消息映射入口需要用户手工加入，Visual C++提供的ClassWizard并不
能替用户完成这一工作。上中例子没有使用PostMessage函数而使用SendMessage函
数的原因是利用了SendMessage函数的特点，即它只有发送消息得到适当处理后方才
返回，这样有助于程序控制。
另一种发送自定义消息的办法是直接发送命令ID，在控制层次上采用ON_MESSAGE来
实现消息映射入口，注意这时的命令控制函数的原型根据Windows本身消息处理的规
定必须如下：
afx_msg LONG OnCaculationOnce(WPARAM wParam,LPARAM lParam);
相对来讲，这种机制不如上述机制简单，也就不再赘述。
七、使用不带文挡-视结构的MFC应用
文档-视结构的功能是非常强大的，可以适合于大多数应用程序，但是有时我们只需
要非常简单的程序，为了减少最终可执行文件尺寸和提高运行速度，我们没有必要
使用文挡-视结构，典型的有简单SDI应用和基于对话框的应用。
1、简单SDI应用
此时只需要使用CWinApp和CFrameWnd两个类就完全可以了。由于CWinApp类封装了
WinMain函数和消息处理循环，因此任何使用MFC进行编程的程序都不能脱离开该
类。实际上使用CWinApp类非常简单，主要是派生一个用户自己的应用类，如
CMyApp，然后只需重载CWinApp类的InitInstance()函数：

BOOL CMyApp::InitInstance()
{
m_pMainWnd=new CMainFrame();
ASSERT(m_pMainWnd!=NULL); //error checking only
m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();
return TRUE;
}
至于所需要的主框架类，则可以直接使用ClassWizard实用程序生成，该类的头文件
与实现代码可以与CMyApp类的头文件和实现代码放在一起。注意，这里由一个技
巧，由于ClassWizard的使用需要有相应的CLW文件存在，而收工建代码时没有对应
的CLW文件，因此不能直接使用，解决办法是进入App Studio实用工具后使用
ClassWizard，此时系统会发觉不存在相应的CLW文件，系统将提示你重建CLW文件并
弹出相应对话框，这时候你不需要选择任何文件就直接选择OK按钮，这样系统将为
你产生一个空的CLW文件，这样就可以使用ClassWizard实用工具了。为了将CWinApp
和CFrameWnd的派生类有机地结合在一起，只需在CFrameWnd派生类的构造函数中进
行窗口创建即可。典型代码如下：
CMainFrame::CMainFrame()
{
Create(NULL,"DDE Client Application",WS_OVERLAPPEDWINDOW,rectDefault,
NULL,MAKEINTRESOURCE(IDR_MAINFRAME));
}
采用ClassWizard实用程序生成相关类代码后，所有的类的其它实现和维护就同普通
由AppWizard实用程序产生的代码一样了。
2、基于对话框的程序
有些主要用于数据的输入和输出等的应用在使用时没有必要改变窗口大小，典型的
如各种联机注册程序，这些使用对话框作为应用的主界面就足够了，而且开发此类
应用具有方便快捷的特点，代码也比较短小，如果直接采用各种控制类生成所需要
的控制就特别麻烦。在Visual C++ 4.x版本中使用AppWizard就可以直接生成基于对
话框的应用。在Visual 1.x中没有此功能，因此这类应用需要程序员自己实现。
实际上使用MFC实现基于对话框的应用非常简单，同样只使用两个MFC类作为基类，
这两个类为CWinApp类和CDialog类。所使用的对话框主界面同样可以先用App
Studio编辑对话框界面，再使用ClassWizard产生相应代码框架，然后修改CMyApp类
的声明，增加一个该对话框类的成员变量m_Mydlg，最后修改CMyApp类的
InitInstance()函数如下：
BOOL CMyApp::InitInstance()
{
m_Mydlg.DoModal();
return TRUE;
}
八、MFC应用的人工优化
使用C/C++编写Windows程序的优点就是灵活高效，运行速度快，Visual C++编译器
本身的优化工作相当出色，但这并不等于不需要进行适当的人工优化，为了提高程
序的运行速度，程序员可以从以下几方面努力：
1) 减少不必要的重复显示
相对来讲，Windows的GDI操作是比较慢的，因此在程序中我们应该尽可能地控制整
个视口的显示和更新，如果前后两此数据不发生变化，那么就不要重新进行视口的
GDI图形操作，尤其对于背景图显示时非万不得已时不要重绘，同时不要经常五必要
的刷新整个窗口。
2) 在视口极小化时不要进行更新屏幕操作
在窗口处于极小化时没有必要继续进行视口更新工作，这样可以显著提高速度。为
此需要在子窗口一级捕获上述信息（视口不能捕获该类信息），再在视口中进行相
应操作。如下代码片段所示：
首先在子窗口类中添加如下程序段：
void CMyChild::OnSysCommand(UINT nID,LPARAM lparam)
{
CMDIChildWnd::OnSysCommand(nID,lparam);
if(nID==SC_MINIMIZE){
RedrawFlag=0;
}
else
RedrawFlag=1;
}
再在视口更新时中修改如下：
void CMyChart::OnUpdate( CView* pSender, LPARAM lHint, CObject* pHint )
{
if(pChild->RedrawFlag)
{
InvalidateRect(&r,FALSE);
TRACE("Now In CMyChart::OnUpdate\n");
}
}
至于上中pChild指针可以在视口创建的例程中获取：
pChild=(CMyChild*)GetParent();
3) 使用永久性的资源
在频繁进行GDI输出的视口中，如在监控软件中常常使用的趋势图显示和棒图显示等
等，应该考虑在类层次上建立频繁使用的每种画笔和刷子，这可以避免频繁的在堆
中创建和删除GDI对象，从而提高速度。
4) 使用自有设备描述句柄
亦即在创建视口时通过指定WM_OWNDC风格来拥有自己的显示设备句柄，这虽然会多
消耗一些内存，一个DC大约占800字节的内存，但是这避免了每次进行GDI操作前创
建并合理初始化显示设备句柄这些重复操作。特别是要自定义坐标系统和使用特殊
字体的视口这一点尤其重要。在16M机器日益普遍的今天为了节约一点点内存而降低
速度的做法并不可取。
5) 优化编译时指定/G3选项和/FPix87选项
/G3选项将强迫编译器使用386处理器的处理代码，使用嵌入式协处理器指令对那些
频繁进行浮点运算的程序很有帮助。采用这两种编译开关虽然提高了对用户机型的
要求，但在386逐渐被淘汰，486市场大幅度萎缩，586市场日益普及的今天上述问题
已经不再成为问题了。
九、结束语
总体上讲，使用Visual C++和MFC类库进行Windows编程是非常方便的，本文中所提
到的一些看法只代表本人的观点，经验也只是笔者根据近年使用MFC进行Windows编
程的总结，在此写出来是希望对那些使用VC和MFC进行Windows编程的同行有所帮
助，如有不同看法欢迎与笔者联系讨论。
十、参考文献：
[1]. David J.Kruglinski ，Visual C++技术内幕，清华大学出版社，1995
[2]. 郑雪明，Visual C++基础类库参考大全，学苑出版社，1994
[3]. B.R. Overland，Visual C++程序设计精髓，科学出版社，1995
[4]. Mike Klein，Windows程序员使用指南--DLL和内存管理，清华大学出版社，
1995
[5]. Richard Wilton，Microsoft Windows软件开发环境与技术， 清华大学出版
社，1993
[6]. 芶建兵，倪维斗，Windows下网络DDE的使用，电子与电脑，1997.2

前一段用了mscomm控件编写程序，但是部署到新的设备上时需要手工注册控件，很是麻烦，能不能编写一个Winapi的程序自动注册呢？所以就自己写了一个程序。

原理：如何手工来注册安装MSComm控件。

　　第一步：将Mscomm.srg, Mscomm32.ocx,Mscomm32.dep三个文件复制到系统文件夹中。要注意的是，MSComm控件是要授权的，所以必须将其使用“执照”Licence 在注册表中登记注册，下一步就是注册方法。至于为什么要这样做，可以看看下面的网页：http://support.microsoft.com/support/kb/articles/q151/7/71.asp

　　第二步：用Windows下的注册工具regsvr32注册该OCX控件，点击“开始”->"运行"，再在中填入（假设操作安装在C盘，WIN2000）：

      Regsvr32  C:\winnt\system32\Mscomm32.ocx

   　第三步：在注册表中手工新建一个主键项：先在点击“开始”->"运行"，再在中填入regedit命令打开注册表，找到HKEY_CLASSES_ROOT\Licenses，在其中添加主键
4250E830-6AC2-11cf-8ADB-00AA00C00905　并将内容设置为：

　　　　　　　kjljvjjjoquqmjjjvpqqkqmqykypoqjquoun

　　　（注：这项内容也可以用记事本程序打开Mscomm.srg文件看到）

这是手工注册的过程，非常繁琐。我得程序也是按照这个顺序执行的。

源代码：

//
#include <windows.h>
#include <stdio.h>
#include <string.h>

void CPFile(char file);
void regsted();
void regOCX();

void CPFile(char file[],char tarpath[]) //将三个文件拷贝到系统目录
{
 char tempsys[100];
    char *r;
 char *t;

 r=tarpath;
 t=tempsys;
 strcpy(t,r);

 char path[256];
 char *p;
 char *q;
    GetModuleFileName(GetModuleHandle(NULL),path,sizeof(path));
 
    p = path;
 while(strchr(p,'\\'))
 {
  p = strchr(p,'\\');   
        p++; 
 }
    *p = '\0';

 p=strchr(path,'\0');
    q=file;
 strcpy(p,q);
   
    p=strchr(tempsys,'\0');
 *p = '\\';
  p++;

    q=file;
 strcpy(p,q);
   
 CopyFile(path,tempsys,FALSE);

}

void regsted()   //将相关信息写入注册表
{
 HKEY hKey;
    DWORD dwDip;
 LPBYTE owner_Get=new BYTE[80];
 DWORD type_1=REG_SZ;
 DWORD cbData_1=80;
 long exist=RegQueryValueEx(HKEY_CLASSES_ROOT, "Licenses\\4250E830-6AC2-11cf-8ADB-00AA00C00905", NULL, &type_1, owner_Get, &cbData_1);

    if(exist!=ERROR_SUCCESS)
 {
   long ret =  RegCreateKeyEx(HKEY_CLASSES_ROOT,"Licenses\\4250E830-6AC2-11cf-8ADB-00AA00C00905",0l,NULL,REG_OPTION_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,&dwDip);
         DWORD leng=37;

   char key[37]="kjljvjjjoquqmjjjvpqqkqmqykypoqjquoun";
         LPBYTE lpb=new BYTE(37);
         for(int i=0;i<37;i++)
      lpb[i]=key[i];
         long ret2 = RegSetValueEx(hKey,NULL,NULL,REG_SZ,lpb,leng);

 }
}

void regOCX()//调用新进程注册组件
{

    char commandline[256];
 char windowsdir[256];
    char lastcommandline[257];

    PROCESS_INFORMATION pi;
    STARTUPINFO si = {sizeof(si)};
   
 char OCXfile[50]="\\MSCOMM32.OCX";
 char REGfile[50]="\\regsvr32.exe";
    char *p,*q;
    GetSystemDirectory(windowsdir, 256);
 p=commandline;
 q=windowsdir;
 strcpy(p,q);

 p=strchr(commandline,'\0');
    q=OCXfile;
 strcpy(p,q);

 p=strchr(windowsdir,'\0');
    q=REGfile;
 strcpy(p,q);

 p=commandline;
 q=&lastcommandline[1];
    strcpy(q,p);
    lastcommandline[0]=' ';
 

    // 启动regsvr32.exe作为子进程
    BOOL ret = CreateProcess(windowsdir, lastcommandline, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
    if(ret)
 {
     CloseHandle(pi.hThread);
   
     CloseHandle(pi.hProcess);

 }

}

int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPSTR     lpCmdLine,
                     int       nCmdShow )
{

    char sys[100];

    char file1[20]="Mscomm32.ocx";
 char file2[20]="Mscomm32.dep";
 char file3[20]="Mscomm.srg";

 GetSystemDirectory(sys,100);

    CPFile(file1,sys);
 CPFile(file2,sys);
 CPFile(file3,sys);

    regOCX();
 
 regsted();

 return 0;
}

        原始模型模式的对象创建方式有两种，可以分别称为浅复制和深复制：浅复制就是从原对象复制出新的对象时，并不复制它的成员对象，即它的成员对象句柄所指向的还是原对象中的成员对象；深复制就是在新对象中，成员对象也是新的。

package  prototype;

public   interface  Prototype  ... {

     public   void  printPart();
    
    Object flatClone();
    
    Object deepClone()  throws  Exception;
    
}


package  prototype;

import  java.io. * ;

public   class  ConcretePrototype  implements  Prototype , Serializable ... {

     private  Part part;
    
     public  ConcretePrototype()  ... {
        part  =   new  Part();
    }
    
     public   void  printPart()  ... {
        System.out.println(part);
    }
    

     public  Object flatClone()  ... {
        ConcretePrototype cp  =   new  ConcretePrototype();
        cp.part  =   this .part;
         return  cp;
    }

    
     public  Object deepClone()  throws  Exception  ... {
        ByteArrayOutputStream bo  =   new  ByteArrayOutputStream();
        ObjectOutputStream oo  =   new  ObjectOutputStream(bo);
        oo.writeObject( this );
        ByteArrayInputStream bi  =   new  ByteArrayInputStream(bo.toByteArray());
        ObjectInputStream oi  =   new  ObjectInputStream(bi);
         return  (oi.readObject());
    }

     class  Part  implements  Serializable  ... {
        
    }
    
}


package  prototype;

public   class  Client  ... {
    
     public   static   void  main(String[] args)  throws  Exception  ... {
        ConcretePrototype originate, cloned, deepCloned;
        originate  =   new  ConcretePrototype();

        Thread.sleep( 2000 );

        cloned  =  (ConcretePrototype)originate.flatClone();
        deepCloned  =  (ConcretePrototype)originate.deepClone();
        System.out.println(originate);
        System.out.println(cloned);
        System.out.println(deepCloned);
        originate.printPart();
        cloned.printPart();
        deepCloned.printPart();
    }

}

    下面是这段代码的打印：

prototype.ConcretePrototype@1034bb5
prototype.ConcretePrototype@19efb05
prototype.ConcretePrototype@723d7c
prototype.ConcretePrototype$Part@b162d5
prototype.ConcretePrototype$Part@b162d5
prototype.ConcretePrototype$Part@22c95b

　　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。

　　本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

　　个人特征

　　软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。

　　愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

　　具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。

　　自觉主动;积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

　　抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

　　开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

　　有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。

　　跟踪生命周期

　　好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson 的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

　　SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。

• 　　分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
• 　　设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
• 　　实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
• 　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
• 　　维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

　　架构师培养建议

　　有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保证，即使最好的体系结构也毫无用处。

　　组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。

　　结束语

　　开发人员一旦迈出了通向体系结构设计专业方向的第一步，就可以利用很多资源来获得帮助，其中包括很多来自 IBM 的资源。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。

　　第二，Anonymous Inner Class (匿名内部类) 是否可以extends(继承)其它类，是否可以implements(实现)interface(接口)?

　　第三，Static Nested Class 和 Inner Class的不同，说得越多越好(面试题有的很笼统)。

　　第四，&和&&的区别。

　　第五，HashMap和Hashtable的区别。

　　第六，Collection 和 Collections的区别。

　　第七，什么时候用assert。

　　第八，GC是什么? 为什么要有GC?

　　第九，String s = new String("xyz");创建了几个String Object?

　　第十，Math.round(11.5)等於多少? Math.round(-11.5)等於多少?

　　第十一，short s1 = 1; s1 = s1 + 1;有什么错? short s1 = 1; s1 += 1;有什么错?

　　第十二，sleep() 和 wait() 有什么区别?

　　第十三，Java有没有goto?

　　第十四，数组有没有length()这个方法? String有没有length()这个方法?

　　第十五，Overload和Override的区别。Overloaded的方法是否可以改变返回值的类型?

　　第十六，Set里的元素是不能重复的，那么用什么方法来区分重复与否呢? 是用==还是equals()? 它们有何区别?

　　第十七，给我一个你最常见到的runtime exception。

　　第十八，error和exception有什么区别?

　　第十九，List, Set, Map是否继承自Collection接口?

　　第二十，abstract class和interface有什么区别?

　　第二十一，abstract的method是否可同时是static,是否可同时是native，是否可同时是synchronized?

　　第二十二，接口是否可继承接口? 抽象类是否可实现(implements)接口? 抽象类是否可继承实体类(concrete class)?

　　第二十三，启动一个线程是用run()还是start()?

　　第二十四，构造器Constructor是否可被override?

　　第二十五，是否可以继承String类?

　　第二十六，当一个线程进入一个对象的一个synchronized方法后，其它线程是否可进入此对象的其它方法?

　　第二十七，try {}里有一个return语句，那么紧跟在这个try后的finally {}里的code会不会被执行，什么时候被执行，在return前还是后?

　　第二十八，编程题: 用最有效率的方法算出2乘以8等於几?

　　第二十九，两个对象值相同(x.equals(y) == true)，但却可有不同的hash code，这句话对不对?

　　第三十，当一个对象被当作参数传递到一个方法后，此方法可改变这个对象的属性，并可返回变化后的结果，那么这里到底是值传递还是引用传递?

　　第三十一，swtich是否能作用在byte上，是否能作用在long上，是否能作用在String上?

　　第三十二，编程题: 写一个Singleton出来。

　　答案请参看楼下：
以下是答案

　　第一，谈谈final, finally, finalize的区别。

　　final?修饰符（关键字）如果一个类被声明为final，意味着它不能再派生出新的子类，不能作为父类被继承。因此一个类不能既被声明为 abstract的，又被声明为final的。将变量或方法声明为final，可以保证它们在使用中不被改变。被声明为final的变量必须在声明时给定初值，而在以后的引用中只能读取，不可修改。被声明为final的方法也同样只能使用，不能重载finally?再异常处理时提供 finally 块来执行任何清除操作。如果抛出一个异常，那么相匹配的 catch 子句就会执行，然后控制就会进入 finally 块（如果有的话）。

　　finalize?方法名。Java 技术允许使用 finalize() 方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。这个方法是由垃圾收集器在确定这个对象没有被引用时对这个对象调用的。它是在 Object 类中定义的，因此所有的类都继承了它。子类覆盖 finalize() 方法以整理系统资源或者执行其他清理工作。finalize() 方法是在垃圾收集器删除对象之前对这个对象调用的。

　　第二，Anonymous Inner Class (匿名内部类) 是否可以extends(继承)其它类，是否可以implements(实现)interface(接口)?

　　匿名的内部类是没有名字的内部类。不能extends(继承) 其它类，但一个内部类可以作为一个接口，由另一个内部类实现。

　　第三，Static Nested Class 和 Inner Class的不同，说得越多越好(面试题有的很笼统)。

　　Nested Class （一般是C++的说法），Inner Class (一般是JAVA的说法)。Java内部类与C++嵌套类最大的不同就在于是否有指向外部的引用上。具体可见http: //www.frontfree.net/articles/services/view.asp?id=704&page=1

　　注： 静态内部类（Inner Class）意味着1创建一个static内部类的对象，不需要一个外部类对象，2不能从一个static内部类的一个对象访问一个外部类对象

　　第四，&和&&的区别。

　　&是位运算符。&&是布尔逻辑运算符。

　　第五，HashMap和Hashtable的区别。

　　都属于Map接口的类，实现了将惟一键映射到特定的值上。

　　HashMap 类没有分类或者排序。它允许一个 null 键和多个 null 值。

　　Hashtable 类似于 HashMap，但是不允许 null 键和 null 值。它也比 HashMap 慢，因为它是同步的。

　　第六，Collection 和 Collections的区别。

　　Collections是个java.util下的类，它包含有各种有关集合操作的静态方法。
　　Collection是个java.util下的接口，它是各种集合结构的父接口。

　　第七，什么时候用assert。

　　断言是一个包含布尔表达式的语句，在执行这个语句时假定该表达式为 true。如果表达式计算为 false，那么系统会报告一个 AssertionError。它用于调试目的：

assert(a > 0); // throws an AssertionError if a <= 0

　　断言可以有两种形式：

　　assert Expression1 ;
　　assert Expression1 : Expression2 ;

　　Expression1 应该总是产生一个布尔值。
　　Expression2 可以是得出一个值的任意表达式。这个值用于生成显示更多调试信息的 String 消息。
断言在默认情况下是禁用的。要在编译时启用断言，需要使用 source 1.4 标记：

　　javac -source 1.4 Test.java

　　要在运行时启用断言，可使用 -enableassertions 或者 -ea 标记。
　　要在运行时选择禁用断言，可使用 -da 或者 -disableassertions 标记。
　　要系统类中启用断言，可使用 -esa 或者 -dsa 标记。还可以在包的基础上启用或者禁用断言。

　　可以在预计正常情况下不会到达的任何位置上放置断言。断言可以用于验证传递给私有方法的参数。不过，断言不应该用于验证传递给公有方法的参数，因为不管是否启用了断言，公有方法都必须检查其参数。不过，既可以在公有方法中，也可以在非公有方法中利用断言测试后置条件。另外，断言不应该以任何方式改变程序的状态。

　　第八，GC是什么? 为什么要有GC? (基础)。

　　GC是垃圾收集器。Java 程序员不用担心内存管理，因为垃圾收集器会自动进行管理。要请求垃圾收集，可以调用下面的方法之一：

　　System.gc()
　　Runtime.getRuntime().gc()

　　第九，String s = new String("xyz");创建了几个String Object?

　　两个对象，一个是“xyx”,一个是指向“xyx”的引用对象s。

　　第十，Math.round(11.5)等於多少? Math.round(-11.5)等於多少?

　　Math.round(11.5)返回（long）12，Math.round(-11.5)返回（long）-11;

　　第十一，short s1 = 1; s1 = s1 + 1;有什么错? short s1 = 1; s1 += 1;有什么错?

　　short s1 = 1; s1 = s1 + 1;有错，s1是short型，s1+1是int型,不能显式转化为short型。可修改为s1 =(short)(s1 + 1) 。short s1 = 1; s1 += 1正确。

　　第十二，sleep() 和 wait() 有什么区别? 搞线程的最爱

　　sleep()方法是使线程停止一段时间的方法。在sleep 时间间隔期满后，线程不一定立即恢复执行。这是因为在那个时刻，其它线程可能正在运行而且没有被调度为放弃执行，除非(a)“醒来”的线程具有更高的优先级，(b)正在运行的线程因为其它原因而阻塞。

　　wait()是线程交互时，如果线程对一个同步对象x 发出一个wait()调用，该线程会暂停执行，被调对象进入等待状态，直到被唤醒或等待时间到。

第十三，Java有没有goto?

　　Goto?java中的保留字，现在没有在java中使用。

　　第十四，数组有没有length()这个方法? String有没有length()这个方法？

　　数组没有length()这个方法，有length的属性。
　　String有有length()这个方法。

　　第十五，Overload和Override的区别。Overloaded的方法是否可以改变返回值的类型?

　　方法的重写Overriding和重载Overloading是Java多态性的不同表现。重写Overriding是父类与子类之间多态性的一种表现，重载Overloading是一个类中多态性的一种表现。如果在子类中定义某方法与其父类有相同的名称和参数，我们说该方法被重写 (Overriding)。子类的对象使用这个方法时，将调用子类中的定义，对它而言，父类中的定义如同被“屏蔽”了。如果在一个类中定义了多个同名的方法，它们或有不同的参数个数或有不同的参数类型，则称为方法的重载(Overloading)。Overloaded的方法是可以改变返回值的类型。

　　第十六，Set里的元素是不能重复的，那么用什么方法来区分重复与否呢? 是用==还是equals()? 它们有何区别?

　　Set里的元素是不能重复的，那么用iterator()方法来区分重复与否。equals()是判读两个Set是否相等。

　　equals()和==方法决定引用值是否指向同一对象equals()在类中被覆盖，为的是当两个分离的对象的内容和类型相配的话，返回真值。

　　第十七，给我一个你最常见到的runtime exception。

　　ArithmeticException, ArrayStoreException, BufferOverflowException, BufferUnderflowException, CannotRedoException, CannotUndoException, ClassCastException, CMMException, ConcurrentModificationException, DOMException, EmptyStackException, IllegalArgumentException, IllegalMonitorStateException, IllegalPathStateException, IllegalStateException,
ImagingOpException, IndexOutOfBoundsException, MissingResourceException, NegativeArraySizeException, NoSuchElementException, NullPointerException, ProfileDataException, ProviderException, RasterFormatException, SecurityException, SystemException, UndeclaredThrowableException, UnmodifiableSetException, UnsupportedOperationException

　　第十八，error和exception有什么区别?

　　error 表示恢复不是不可能但很困难的情况下的一种严重问题。比如说内存溢出。不可能指望程序能处理这样的情况。

　　exception 表示一种设计或实现问题。也就是说，它表示如果程序运行正常，从不会发生的情况。

　　第十九，List, Set, Map是否继承自Collection接口?

　　List，Set是

　　Map不是

　　第二十，abstract class和interface有什么区别?

　　声明方法的存在而不去实现它的类被叫做抽象类（abstract class），它用于要创建一个体现某些基本行为的类，并为该类声明方法，但不能在该类中实现该类的情况。不能创建abstract 类的实例。然而可以创建一个变量，其类型是一个抽象类，并让它指向具体子类的一个实例。不能有抽象构造函数或抽象静态方法。Abstract 类的子类为它们父类中的所有抽象方法提供实现，否则它们也是抽象类为。取而代之，在子类中实现该方法。知道其行为的其它类可以在类中实现这些方法。

　　接口（interface）是抽象类的变体。在接口中，所有方法都是抽象的。多继承性可通过实现这样的接口而获得。接口中的所有方法都是抽象的，没有一个有程序体。接口只可以定义static final成员变量。接口的实现与子类相似，除了该实现类不能从接口定义中继承行为。当类实现特殊接口时，它定义（即将程序体给予）所有这种接口的方法。然后，它可以在实现了该接口的类的任何对象上调用接口的方法。由于有抽象类，它允许使用接口名作为引用变量的类型。通常的动态联编将生效。引用可以转换到接口类型或从接口类型转换，instanceof 运算符可以用来决定某对象的类是否实现了接口。

　　第二十一，abstract的method是否可同时是static,是否可同时是native，是否可同时是synchronized?

　　都不能

　　第二十二，接口是否可继承接口? 抽象类是否可实现(implements)接口? 抽象类是否可继承实体类(concrete class)?

　　接口可以继承接口。抽象类可以实现(implements)接口，抽象类是否可继承实体类，但前提是实体类必须有明确的构造函数。

　　第二十三，启动一个线程是用run()还是start()?

　　启动一个线程是调用start()方法，使线程所代表的虚拟处理机处于可运行状态，这意味着它可以由JVM调度并执行。这并不意味着线程就会立即运行。run()方法可以产生必须退出的标志来停止一个线程。

　　第二十四，构造器Constructor是否可被override?

　　构造器Constructor不能被继承，因此不能重写Overriding，但可以被重载Overloading。

　　第二十五，是否可以继承String类?

　　String类是final类故不可以继承。

　　第二十六，当一个线程进入一个对象的一个synchronized方法后，其它线程是否可进入此对象的其它方法?

　　不能，一个对象的一个synchronized方法只能由一个线程访问。

　　第二十七，try {}里有一个return语句，那么紧跟在这个try后的finally {}里的code会不会被执行，什么时候被执行，在return前还是后?

　　会执行，在return前执行。

　　第二十八，编程题: 用最有效率的方法算出2乘以8等於几?

　　有C背景的程序员特别喜欢问这种问题。

　　2 << 3

　　第二十九，两个对象值相同(x.equals(y) == true)，但却可有不同的hash code，这句话对不对?

　　不对，有相同的hash code。

　　第三十，当一个对象被当作参数传递到一个方法后，此方法可改变这个对象的属性，并可返回变化后的结果，那么这里到底是值传递还是引用传递?

　　是值传递。Java 编程语言只由值传递参数。当一个对象实例作为一个参数被传递到方法中时，参数的值就是对该对象的引用。对象的内容可以在被调用的方法中改变，但对象的引用是永远不会改变的。

　　第三十一，swtich是否能作用在byte上，是否能作用在long上，是否能作用在String上?

　　switch（expr1）中，expr1是一个整数表达式。因此传递给 switch 和 case 语句的参数应该是 int、 short、 char 或者 byte。long,string 都不能作用于swtich。

　　第三十二，编程题: 写一个Singleton出来。

　　Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。

　　一般Singleton模式通常有几种种形式:

　　第一种形式: 定义一个类，它的构造函数为private的，它有一个static的private的该类变量，在类初始化时实例话，通过一个public的getInstance方法获取对它的引用,继而调用其中的方法。

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; 　　}
}

　　其他形式:

　　定义一个类，它的构造函数为private的，所有方法为static的。

　　一般认为第一种形式要更加安全些

　　第三十三 Hashtable和HashMap

　　Hashtable继承自Dictionary类，而HashMap是Java1.2引进的Map interface的一个实现

　　HashMap允许将null作为一个entry的key或者value，而Hashtable不允许

　　还有就是，HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey。因为contains方法容易让人引起误解。

　　最大的不同是，Hashtable的方法是Synchronize的，而HashMap不是，在多个线程访问Hashtable时，不需要自己为它的方法实现同步，而HashMap就必须为之提供外同步。

　　Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异。

　　
　　转java中文站

对于这个系列里的问题，每个学Java的人都应该搞懂。当然，如果只是学Java玩玩就无所谓了。如果你认为自己已经超越初学者了，却不很懂这些问题，请将你自己重归初学者行列。内容均来自于CSDN的经典老贴。

问题一：我声明了什么！

String s = "Hello world!";

许多人都做过这样的事情，但是，我们到底声明了什么？回答通常是：一个String，内容是“Hello world!”。这样模糊的回答通常是概念不清的根源。如果要准确的回答，一半的人大概会回答错误。
这个语句声明的是一个指向对象的引用，名为“s”，可以指向类型为String的任何对象，目前指向"Hello world!"这个String类型的对象。这就是真正发生的事情。我们并没有声明一个String对象，我们只是声明了一个只能指向String对象的引用变量。所以，如果在刚才那句语句后面，如果再运行一句：

String string = s;

我们是声明了另外一个只能指向String对象的引用，名为string，并没有第二个对象产生，string还是指向原来那个对象，也就是，和s指向同一个对象。

问题二："=="和equals方法究竟有什么区别？

==操作符专门用来比较变量的值是否相等。比较好理解的一点是：
int a=10;
int b=10;
则a==b将是true。
但不好理解的地方是：
String a=new String("foo");
String b=new String("foo");
则a==b将返回false。

根据前一帖说过，对象变量其实是一个引用，它们的值是指向对象所在的内存地址，而不是对象本身。a和b都使用了new操作符，意味着将在内存中产生两个内容为"foo"的字符串，既然是“两个”，它们自然位于不同的内存地址。a和b的值其实是两个不同的内存地址的值，所以使用"=="操作符，结果会是false。诚然，a和b所指的对象，它们的内容都是"foo"，应该是“相等”，但是==操作符并不涉及到对象内容的比较。
对象内容的比较，正是equals方法做的事。

看一下Object对象的equals方法是如何实现的：
boolean equals(Object o){

return this==o;

}
Object对象默认使用了==操作符。所以如果你自创的类没有覆盖equals方法，那你的类使用equals和使用==会得到同样的结果。同样也可以看出，Object的equals方法没有达到equals方法应该达到的目标：比较两个对象内容是否相等。因为答案应该由类的创建者决定，所以Object把这个任务留给了类的创建者。

看一下一个极端的类：
Class Monster{
private String content;
...
boolean equals(Object another){ return true;}

}
我覆盖了equals方法。这个实现会导致无论Monster实例内容如何，它们之间的比较永远返回true。

所以当你是用equals方法判断对象的内容是否相等，请不要想当然。因为可能你认为相等，而这个类的作者不这样认为，而类的equals方法的实现是由他掌握的。如果你需要使用equals方法，或者使用任何基于散列码的集合（HashSet,HashMap,HashTable），请察看一下java doc以确认这个类的equals逻辑是如何实现的。

问题三：String到底变了没有？

没有。因为String被设计成不可变(immutable)类，所以它的所有对象都是不可变对象。请看下列代码：

String s = "Hello";
s = s + " world!";

s所指向的对象是否改变了呢？从本系列第一篇的结论很容易导出这个结论。我们来看看发生了什么事情。在这段代码中，s原先指向一个String对象，内容是"Hello"，然后我们对s进行了+操作，那么s所指向的那个对象是否发生了改变呢？答案是没有。这时，s不指向原来那个对象了，而指向了另一个String对象，内容为"Hello world!"，原来那个对象还存在于内存之中，只是s这个引用变量不再指向它了。
通过上面的说明，我们很容易导出另一个结论，如果经常对字符串进行各种各样的修改，或者说，不可预见的修改，那么使用String来代表字符串的话会引起很大的内存开销。因为String对象建立之后不能再改变，所以对于每一个不同的字符串，都需要一个String对象来表示。这时，应该考虑使用StringBuffer类，它允许修改，而不是每个不同的字符串都要生成一个新的对象。并且，这两种类的对象转换十分容易。
同时，我们还可以知道，如果要使用内容相同的字符串，不必每次都new一个String。例如我们要在构造器中对一个名叫s的String引用变量进行初始化，把它设置为初始值，应当这样做：
public class Demo {
private String s;
...
public Demo {
s = "Initial Value";
}
...
}
而非
s = new String("Initial Value");
后者每次都会调用构造器，生成新对象，性能低下且内存开销大，并且没有意义，因为String对象不可改变，所以对于内容相同的字符串，只要一个String对象来表示就可以了。也就说，多次调用上面的构造器创建多个对象，他们的String类型属性s都指向同一个对象。
上面的结论还基于这样一个事实：对于字符串常量，如果内容相同，Java认为它们代表同一个String对象。而用关键字new调用构造器，总是会创建一个新的对象，无论内容是否相同。
至于为什么要把String类设计成不可变类，是它的用途决定的。其实不只String，很多Java标准类库中的类都是不可变的。在开发一个系统的时候，我们有时候也需要设计不可变类，来传递一组相关的值，这也是面向对象思想的体现。不可变类有一些优点，比如因为它的对象是只读的，所以多线程并发访问也不会有任何问题。当然也有一些缺点，比如每个不同的状态都要一个对象来代表，可能会造成性能上的问题。所以Java标准类库还提供了一个可变版本，即StringBuffer。
问题四：final关键字到底修饰了什么？

final使得被修饰的变量"不变"，但是由于对象型变量的本质是“引用”，使得“不变”也有了两种含义：引用本身的不变，和引用指向的对象不变。

引用本身的不变：
final StringBuffer a=new StringBuffer("immutable");
final StringBuffer b=new StringBuffer("not immutable");
a=b;//编译期错误

引用指向的对象不变：
final StringBuffer a=new StringBuffer("immutable");
a.append(" broken!"); //编译通过

可见，final只对引用的“值”(也即它所指向的那个对象的内存地址)有效，它迫使引用只能指向初始指向的那个对象，改变它的指向会导致编译期错误。至于它所指向的对象的变化，final是不负责的。这很类似==操作符：==操作符只负责引用的“值”相等，至于这个地址所指向的对象内容是否相等，==操作符是不管的。

理解final问题有很重要的含义。许多程序漏洞都基于此----final只能保证引用永远指向固定对象，不能保证那个对象的状态不变。在多线程的操作中,一个对象会被多个线程共享或修改，一个线程对对象无意识的修改可能会导致另一个使用此对象的线程崩溃。一个错误的解决方法就是在此对象新建的时候把它声明为final，意图使得它“永远不变”。其实那是徒劳的。

问题五：到底要怎么样初始化！

本问题讨论变量的初始化，所以先来看一下Java中有哪些种类的变量。
1. 类的属性，或者叫值域
2. 方法里的局部变量
3. 方法的参数

对于第一种变量，Java虚拟机会自动进行初始化。如果给出了初始值，则初始化为该初始值。如果没有给出，则把它初始化为该类型变量的默认初始值。

int类型变量默认初始值为0
float类型变量默认初始值为0.0f
double类型变量默认初始值为0.0
boolean类型变量默认初始值为false
char类型变量默认初始值为0(ASCII码)
long类型变量默认初始值为0
所有对象引用类型变量默认初始值为null，即不指向任何对象。注意数组本身也是对象，所以没有初始化的数组引用在自动初始化后其值也是null。

对于两种不同的类属性，static属性与instance属性，初始化的时机是不同的。instance属性在创建实例的时候初始化，static属性在类加载，也就是第一次用到这个类的时候初始化，对于后来的实例的创建，不再次进行初始化。这个问题会在以后的系列中进行详细讨论。

对于第二种变量，必须明确地进行初始化。如果再没有初始化之前就试图使用它，编译器会抗议。如果初始化的语句在try块中或if块中，也必须要让它在第一次使用前一定能够得到赋值。也就是说，把初始化语句放在只有if块的条件判断语句中编译器也会抗议，因为执行的时候可能不符合if后面的判断条件，如此一来初始化语句就不会被执行了，这就违反了局部变量使用前必须初始化的规定。但如果在else块中也有初始化语句，就可以通过编译，因为无论如何，总有至少一条初始化语句会被执行，不会发生使用前未被初始化的事情。对于try-catch也是一样，如果只有在try块里才有初始化语句，编译部通过。如果在catch或finally里也有，则可以通过编译。总之，要保证局部变量在使用之前一定被初始化了。所以，一个好的做法是在声明他们的时候就初始化他们，如果不知道要出事化成什么值好，就用上面的默认值吧！

其实第三种变量和第二种本质上是一样的，都是方法中的局部变量。只不过作为参数，肯定是被初始化过的，传入的值就是初始值，所以不需要初始化。

问题六：instanceof是什么东东？

instanceof是Java的一个二元操作符，和==，>，<是同一类东东。由于它是由字母组成的，所以也是Java的保留关键字。它的作用是测试它左边的对象是否是它右边的类的实例，返回boolean类型的数据。举个例子：

String s = "I AM an Object!";
boolean isObject = s instanceof Object;

我们声明了一个String对象引用，指向一个String对象，然后用instancof来测试它所指向的对象是否是Object类的一个实例，显然，这是真的，所以返回true，也就是isObject的值为True。
instanceof有一些用处。比如我们写了一个处理账单的系统，其中有这样三个类：

public class Bill {//省略细节}
public class PhoneBill extends Bill {//省略细节}
public class GasBill extends Bill {//省略细节}

在处理程序里有一个方法，接受一个Bill类型的对象，计算金额。假设两种账单计算方法不同，而传入的Bill对象可能是两种中的任何一种，所以要用instanceof来判断：

public double calculate(Bill bill) {
if (bill instanceof PhoneBill) {
//计算电话账单
}
if (bill instanceof GasBill) {
//计算燃气账单
}
...
}
这样就可以用一个方法处理两种子类。

然而，这种做法通常被认为是没有好好利用面向对象中的多态性。其实上面的功能要求用方法重载完全可以实现，这是面向对象变成应有的做法，避免回到结构化编程模式。只要提供两个名字和返回值都相同，接受参数类型不同的方法就可以了：

public double calculate(PhoneBill bill) {
//计算电话账单
}

public double calculate(GasBill bill) {
//计算燃气账单
}

所以，使用instanceof在绝大多数情况下并不是推荐的做法，应当好好利用多态。

http://www.javaresearch.org/faq/thread.jsp?column=723&thread=22395

作者简介：侯捷，台湾电脑技术作家，着译评兼擅。常着文章自娱，颇示己志。
个人网站：www.jjhou.com
北京镜站：www.csdn.net/expert/jjhou

--------------------------------------------------------------------------------

「侯捷观点」进行了4期。通过这个专栏的作用，我开始接触大陆的电脑技术刊物《程序员》和电脑技术网站 CSDN，并累积了相当量的观察和感想。这个专栏前数期谈的都是技术，不是深度书评就是高阶技法。这一期让我们轻松一下，谈谈程序员（programmer）与编程（programming）。其中不少议题起因於读者来信的触发，许多观点我也已经回应於侯捷网站上。所以若干文字可能你曾经在侯捷网站上阅读过。有些看法也许读来刺眼，听来刺耳。但如果大家不把我视为外人，当能平心静气地思考。台湾存在许多相同的问题，我也时常为文针砭。

有一句话这麽说：如果你想使人发怒，就说谎。如果你想使人大怒，就说实话。说实话的人来了，但愿你心平气和。

急功近利是大忌
一位读者写信给我，说他非常着急。他一个月挣300元人民币，家里情况又不好。他希望赶快把 VC/MFC 学会，进入 IT 产业挣钱。信写得很长，看着看着，我也不禁为他着急起来。

有许多读者，虽然情况没有那麽急迫，燃眉之情却也溢於言表。不外乎都是希望能够尽快把某技术某技术学习起来。

但是哪一样东西哪一样技术是可以快速学成的呢？能够快速学成的技术，人才也就必然易取易得，根据市场供需法则，也就不可能有很好的报酬。所以诸君当有心理准备，门槛高的，学习代价高，报酬高；门槛低的，学习代价低，报酬低。

说起来是老生常谈了。这其中最可怕的心理在急功近利。从读者的来信，以及从 CSDN 上的众多帖文，我感觉，许许多多人学习 IT 技术，进入 IT 产业，是认为 IT 产业可以助你脱困，远离贫穷。
 

是的，IT 产业有这个「钱」景，但你得有那份实力。要吃硬核桃，也得先估量自己的牙口。

「好利」是基本人性，Acer 总裁施振荣先生大力提倡「好逸恶劳」之说，视为人性之本，进步的原动力。谁能说不是呢？好利可以，近利就不妙了。近利代表目光浅短，一切作为都因此只在小格局中打转。

梨园有句话：要在人前显贵，就要在人後受罪。台上一分钟，台下十年功。老祖宗这方面的教诲太多了，身为中国人的我们，应该都耳熟能详。

对於心急的朋友，我只有一句话：勿在浮沙筑高台。你明明很清楚这个道理，为什麽临到自己身上，就糊涂了？急是没有用的，浮躁更会坏事。耐住性子扎根基吧。做任何事都要投资，扎根基就是你对自己的未来的投资。如果想知道如何按部就班扎根基，侯捷网站上有一篇文章：「97/06 选义按部 考辞就班」，请你看看。

口舌之战有何益
最常在程序技术相关论坛上看到毫无价值而又总是人声鼎沸的口舌之战，就是诸如「VB 和 Delphi 谁好」、「BCB 和 VC 谁优」、「Linus 和 Windows 谁棒」、「Java 和 C++ 谁强」这种题目。每次出场都一片洋洋洒洒，红红火火急速窜升为超酷话题。众人各拥所好，口沫飞扬，但是从来说服不了任何异阵营的人，话都只说给自己人听，给自己人爽。

这样的论战有何意义？许多人在重组自己的偏见时，还以为自己在思考呢。战到最後，就只是争谁说最後一句话而已。而且，擦伤引起的争吵几乎总是以刺伤结束。

工具与技术的评比，是一场高水准的演出。真有能力做评比，侯捷是很尊敬的。但是这些各拥所好，口沫飞扬的人，真的对评比两造都有深刻的了解吗？很多时候我们看到的只是无知，而无知是这麽一种东西 : 当你拥有了它，你就拥有巨大的胆量。

很多人喜欢某种工具，只不过因为那是他的初体验。他玩它玩出了一点心得，可以说出它的某些好，就开始做「评比」了。你只看到牡丹的艳丽，又怎知寒梅的清香，幽兰的空灵？

绝大多数人使用某种工具，不是因为它最好，不是因为众里寻它千百度，仅仅只是因缘际会。虽然说不同的应用环境选择不同的工具，是最伶俐的作为，但我真的怀疑，在现今工具（以及工具背後反映的技术）如此繁复的时空下，有多少人能够同时精通一个以上的同质工具？追二兔不得一兔，我还是认为你精专一样工具，把它发挥到最高效能，获得的利益多些。被大家拿来评比的，都是市场上的佼佼者，还能差到哪里去？能够两雄相争，必然是在技术面、非技术面（资源的普及、品牌的可靠度）各有一片天，你的评比意义大吗？全面吗？

大多数人没有能力同时精通两种同质工具，初学者听了网路上不知名大侠的高论，也不可能有所选择（如果有，怕也只是蒙着头瞎选）。这种没有提供数据，评论者也没有显示任何信誉（credit）的论战，没有任何意义，纯粹只为自己爽。浪费网路资源！

C++ 之父 Bjarne Stroustrup 曾经在他自己的网页上的 FAQ （以及其他许多场合）中回答如下问题。虽然其中谈的是语言，但是扩大到其他层面仍然合适，值得大家好好咀嚼（注：全文由孟岩先生译出，可自侯捷网站浏览）：

Q: 你愿不愿意将C++与别的语言比较？

A: 抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。有不少人邀请我把C++与其它语言相比，我已经决定不做这类事情。在此我想重申一个很久以来我一直强调的观点：语言之间的比较没什麽意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这麽大的代价。另外还需要在广泛的应用领域有充份经验，保持一种不偏不倚客观独立的立场，有 公正无私的信念。...

人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到担忧。作者们尽力表现出公正无私，但最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；同样的缺陷在不那麽出名的语言里就被描述为致命伤。同样的道理，较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是陈年老酒，试问这种比较有何公正性和意义可言？

Q: 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在吗？

A: 当这些评比不够完整，或者出於商业目的，我确实感觉不爽。那些散布最广的比较性评论大多是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它语言好。由於C++被广泛运用，所以C++通常成了黑名单上的头一个名字。通常这类文章被夹在Z语言供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论竟然引用的是那些Z语言开发厂商的员工的文章，而这些经不起考验的文章无非想证明Z是最好的。尤其当评论之中确实有一些零零散散的事实...，特意选择出来的事实虽然好像正确，有时却是完全误导。

以後再看到语言评比文章时，请留心是谁写的，他的表述是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易做到。

我说过了，真正精譬的技术评比，对於相当程度的研究者，是很有价值的，但我很少在论坛上看到精品 ─ 论坛还能有什麽精品，99% 是打屁闲谈没有营养的文字。我们每每在其中看到偏见、我执、以及最後免不了因擦伤而引起的刺伤。这真令人伤感。这些人把时间拿来学习，多好。奉劝各位少花时间瞎打屁，多花时间学习，看些真正的精典，别动不动就在论坛上提问，也别动不动就挂在论坛上看别人的瞎打屁。

不但评比性的话题，大家喜欢强出头，其他话题，情绪性的反应也很多。中国强盛之道，眼前彷佛全压宝在 IT产业（尤其软件工业）上面。程序员被赋予了过多的期许，程序员也自我膨胀了许多。夹杂着民族主义或个人好恶，看到不满意的人事物，就号召大家「黑（hack）」过去。这是什麽心态？比拳头吗？说实话，就算要比拳头大小，「黑」个网站算是什麽尺寸的拳头？网路是个大暗室，君子不欺暗室。

杂志定位在哪里
CSDN上头，前一阵子曾经请大家就《程序员》的定位问题给意见。很热闹。我不知道刊物掌门人在看了那麽多建言之後，有没有收获。猜想是没有   ─ 就算有也恐怕不大。

就像面对书籍一样，读者最直观的感觉，就是要看他所需要的东西。100个人有100种需求，这样的询问得不出总结。隐性读者、不上网的读者、不投票的读者、不写帖文的读者，你又如何知道他的想法。

我以为，只需把握一个原则：永远比大众水平高一个档次，扮演引导者，带领读者接触前沿思想与宏观视野，那就是了。读者本身会成长，不论你把刊物定位在实质技术的哪一个层次，都会有人不满足；今年的读者成长了，不见得明年还是你的读者。唯有保持前沿思想与宏观视野，时常导入新的技术形式、新的思维、专家的见解、意见领袖的看法，才能够长期吸引读者，并对许多人以及整个技术开发环境做出长久的贡献。

美国大物理学家费曼，曾经批评物理课的教学。他说老师老是在传授解物理习题的技巧，而不是从物理的精神层面来启发学生。这一点是不是可以给刊物经营者和刊物读者一点点启发？

以此观之，就我个人的专长领域，STL 之父访谈录、算法大师 Donald Knuth 采访、C++/OOP 大系、GP/STL 大系、将标准C++视为一个新语言┅以及一些总括性、大局观的文章，是我认为最好的主题。此中有侯捷自己的作品，唔，我向来不客气。

当然啦，太形而上的东西是不行的，太过抽象的东西不容易被接受。抽象层次愈高，人的自由度愈大，但抽象思考是层次高的人的专利，要普罗大众能够接受，还需具象细节稍做辅助。

如何长期保持具有前沿思想与宏观视野的稿源？与外国杂志合作是一个既快又好的办法。每一期《程序员》最前数页都有当期重要外文期刊的前沿摘要，可见《程序员》编辑群一直与外文专业期刊保持着阅读上的接触。要挑选合作夥伴，心中一定有谱。

当然啦，与国外合作涉及经费问题。旁人（尤其读者）很难体会或换位思考经费上的种种困难。就像有人痛心疾首义正词严地埋怨 CSDN 速度慢得像蜗牛，却可曾想过网站的资源从哪里来。向你收费，你接受吗？台湾已经倒掉很多很多家着名的网站，我等着看免费的服务撑到几时。

要刊物宏观耐读，读者们也得成熟些。一群很好的读者，才拱得起一本很好的刊物。

下面是一封读者来信：

现在技术发展太快了，国外（甚至印度）在实现「软件工业化」的时候，大陆（至少我周围是这样）还停留在小作坊手工打造的水平。我认为未来的世界不再属于「个人数字英雄」，软件工程似乎比一两项技术更迫切。以您的大局观和丰富的阅历，对这个问题是否有不同的看法，不知您是否愿意就此从技术（或其他）角度写篇文章发表您的见解。

软件工程对整个软件工业的提升，至为重要。但是一个程序员要修练到对「软件工程」这个题目感兴趣，非三五载（甚至更多）不为功。我的意思是什麽呢？我的意思是，这类书籍、这类工具、这类网站、这类刊物，在一个嘈嘈切切、急功近利的环境中难有生存空间。这是为什麽蒋涛先生想要将《程序员》杂志导向软件工程主题时，我对他兴起巨大的尊敬与忧虑的原因。

顺带一提，《程序员》的文字水平一直以来带给我「阅读的乐趣」。这个评语我从来少有机会用在台湾的电脑刊物或电脑书籍上。比起台湾的电脑读物，这里的文字有深度多了。

轻浮躁进没信心
只要上网看看程序员出没的论坛，你就会看到一片浮躁与焦虑。反映出来的就是没有信心。

「C# 推出，Java 将死」，「Java 演进，C++ 将亡」，「.Net 推出，VB程序员死定了」，「Kylix 推出，大夥儿快学」，「Delphi 持续新版，哥儿们别怕」，「我刚学VC，怎麽它就出场了」，「MFC 真的要过时了吗」┅。诸如此类的问题，不知该归类为谣言还是童语？

很奇怪也很感叹，为什麽大家对这类问题如此感到兴趣。那透露出一种肤浅 ─ 没有深刻了解技术本质，因而汲汲营营慌慌张张惶惶惑惑於新工具、新事务、并且认为新的大概一定都是好的。对自己没有信心，对整个环境也没有信心。

有深度的程序员绝对不会在意这种事情。当然，并不是早晚三柱香就万事保平安。并不是告诉自己别在乎别在意，就真的能够不在乎不在意了。那必需是发自内心，胸中自有丘壑的一种笃定，有着好的本质学能做靠山。

台湾 BBS（连线）前阵子也有许多热烈讨论 Java, C#, C++, .NET 的贴信。我把我最欣赏的一封引於下。其最後结语，扩张到任何领域都是合适的。

发信人: algent@kkcity.com.tw (流云), 看板: programming
标  题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
发信站: KKCITY (Sun Feb 18 12:55:49 2001)

以目前台湾业界的情形来看，C\C++ 应该是想成为一个软体工程师的基本技能；至於 Java，如果熟悉 C++，学 Java 应该花不了一个月的时间。

以我个人的观点，Java 的 OO 程度是胜於 C++ 的，而且在这个 Internet盛行的年代，效率的瓶颈在於网路本身的频宽而不在单机执行时的效率，Java 所提供的 Collection framework 是非常威力强大的程式设计工具，又内建了对 Multi-thread 程式的支援，丰富的 class library 让人在设计网路、资料库┅的相关软体时无後顾之忧。

C++ 可能是过去十多年以来最重要的程式语言之一，它的效率显然较Java为佳，但在撰写需要安装在Internet上成千上万种不同厂牌的机器上执行的程式时，相对於Java可能就不是最好的解决方案。

「目前」不需要以 Java 来开发 DeskTop 上的应用程式，因为「当下」而言 Java 撰写的程式相对於 C++ 会占据更多的记忆体且执行效能不彰。

我们不能期待免子游得比鱼快，也不能期待鱼飞得比鹰高。

工程上的需求使得各种场合有不同的适合的程式语言，不必费心去批评 A、推崇B、打压 C。基本的理论比这些事重要多了。

VB 将死？Java 将亡？C++ 将被 Java 取代...，这很重要吗？我用Java 也用 C++，即使明年它们全都被 Java++、C++++、Lisp++、Forth++取代，何有於我哉？FFT 还是 FFT、Dijkstra algorithm 还是Dijkstra algorithm...还是别太担心这些事了...

侯捷除了偶在 BBS 上自说自话外，绝少回应或叁与讨论。看了上封信，忍不住回了一帖：

作者: jjhou (jjhou) 看板: programming
标题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
时间: Fri Feb 23 21:12:14 2001

同意你的看法。写得非常精采。

人到了一个层次，才会去思考事物的本质是什麽，不被浮面的工具所系绊。

熟练工具是必要的，但工具的演化汰换，不是大家在这里关起门来喊爽就好。

Donald Knuth 说：「语言持续演进，那是必要的。不论现在流行什麽语言，你都可以肯定十年二十年之後它不再风光。我总是在自己的书中写些不时髦的东西，但这些东西却值得後代子孙记取。」（注：以上局部是《程序员》2000/12 的译文）

DDJ 1996/04 p18:
"Language keep evolving, and that is necessary. ...Whatever computer language is in fashion, you can guarantee that whitin a decade or two it will be completely out of fashion. In my book, I try to write things that are not trendy, but are things that are going to be worth remembering for other generations."

追求新知固然是一个计算机从业人员该有的态度，但是追求新工具与充实固有知识两者之间，应该取得一个平衡。过犹不及！

再说，凡走过必留下足迹。你现今的任何努力，只要它是扎扎实实的，就绝不至於落空。技术是有累积性的呀，技术总是触类旁通的呀。你说 MFC 和 OWL 就没有累积性，我说有，message map 的原理不一样吗？framework 的工作原理不一样吗？

我个人并非任何语言或任何工具或任何技术的狂热者，我是务实派。对於自称熟稔多种（属性不同的）语言的人，我充满敬畏并保持工作上的距离。要精通一个语言，使自己能发挥其最大效能，不是件容易的事，需要不少精力的投注。99.99% 的人都是凡人，身为凡人的我们，把时间用来精通一（或二）种适合其工作性质的「语言」，比泛泛认识多种「语法」，要高明得多，回报也大得多。

真的，还是别太担心谁将兴起谁将亡的事了吧。

天才的沃土
教育永远是我最关心的议题。教育的重要性绝对不亚於产业。没有好的教育，何来好的产业人才？

学校教育就不提了，那不是侯捷能够着力的地方。虽然我也在大学教书，但一年不过教育数十位学生，影响能有多大？书籍的读者动辄数万人，刊物的读者动辄数十万人，这才是有大影响力的地方。

自修教育如影随形，打你离开学校就跟随你一辈子，重要性远胜於学校教育。谈到自修，离不开读物 ─ 各种型式的书籍和刊物。在咱们程序员这一行，书籍和刊物的情况如何？

下面是一封读者来信：

我记得您说过，到一个地区的书店去逛逛，对这里的IT技术水平就知道大概。这话太得我心了。我学习软件技术5年，花在买书的钱有一万二千（人民币）以上，如今回头来看，绝大部份是垃圾。以前曾经担心：若要到外地工作，这麽多书怎麽带走？现在则是一种心痛的轻松，因为值得带走的书只够一提。学习IT之初，谁不想在产业上做出一番成成绩？但多年之後回首，则恐怕都会为自己当时所处的教育环境痛心。

关於计算机书籍的浮滥、低劣，我收到太多太多的读者反应了。以上只是冰山一角，有兴趣的读者请上侯捷网站看个饱。有些出版社甚至以出烂书闻名，看看这封信：

您想必看过蒋先生在《程序员》上写的文章，知道所谓IT出版四大家。蒋先生可能碍於礼仪，有些地方还没讲透。例如其中的XXX出版社，在译作方面现在已经是一块榜样 粗制滥造的榜样。

再看这封信：

我在您网站中看到了有关对关於xxx 出版社的评价，深有感慨。其实该出版社是大陆IT业引进外文书籍的鼻祖，我们这一辈程序员(92年以前的)就是读该出版社的译着成长起来的（我至少还有两大纸箱xxx出版社的旧书），在那个时候，差不多所有的计算机类图书都是它们引进并翻译的，现在看来，那个时候的翻译质量差得无法忍受（比Incide VC++ 5/e还差许多），但我们那个时候已经很满足了，毕竟有比没有好。现在大家对xxx出版社的批评，我想是竞争的结果，因为大家看到了更好的译着，有了比较。总而言之，xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够在尽快的读到优秀作品。这种作风显然已经不合时宜了，或者说它已经完成了它的历史使命。我现在当然也不象从前那样狂买xxx 出版社的书了，因为有了更多的选择。

这封信让我跌入回忆。台湾也曾有两家出版社，有过同等劣质的作法。这两家恶贯满盈的出版社，一名莹圃，一叫松格。两家都关门了。他们的作法都是，快速而大量地翻译外文书。由於速度快，也由於选材之中不乏好书，所以曾经拥有一定的市场。怎地都关门了？因为读者只能被欺负一次两次，不会永远当傻瓜。这样的出版心态摆明没有长远打算，只想捞一票走人，不关门才怪。

我们可能因为，垃圾堆中多少捡过一些经过修补尚称堪用的东西，而对刻意制造这些垃圾的人产生一种奇怪的情愫。东西明明不好，但我们从中吸收了一点点养份。该谢他还是该恨他？

该唾弃他！

这些商人之所以大量而快速地引进外文书，因为有利可图。有利可图是好事，但他没把他该做的事做好。他们放弃品质而无所惧，因为他们知道，在怎样的时空背景下可以怎样轻松地赚钱。大陆出版界朋友告诉我，谁谁谁（都有名有姓）很轻松地在几年里就这样积聚了几百万人民币的身家。几百万人民币呀，我的天。这也算 IT 产业吧，果然是一片红火，鸡犬升天。

因努力做事而致富，应该得到我们的赞美和祝福。可这样的出版社，花更大的功夫赚更多更长远的钱他们不要，因为轻松钱赚起来不费劲儿。百分之一的人可能从这些垃圾中吸收到一些养份，百分之百的人从中感受了阅读的痛苦。谁知道从中被误导的人又有百分之几？买书的钱我们没少花，得到的正价值却是那麽少，痛苦指数那麽高。

这位读者说『总而言之xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够尽快的读到优秀作品』，又说『它们引进并翻译的，现在看来，翻译质量差得无法忍受』。喔，一本优秀的原作，经过无法忍受的翻译质量洗礼後，还会是一本优秀的作品吗？待人宽厚是美德，但是刻意制造馊水油让人吃坏肚子者，不值得为他们说话。你说『它已经完成了它的历史使命』。不，他们从来就没有历史使命，也没有使命。

如此「仁厚自持」而且忍耐度奇佳的读者，相当稀少。绝大部份程序员谈到计算机图书，都是斑斑血泪的控诉。《程序员》2001/03 p119 可不就有一篇「计算机图书出版商的陷阱」。

读者来信写道：

鲁迅说，未有天才之前，应该要先营造天才的土壤。...您的心情我确实能够深刻理解（这大概就是堆在墙角那几百本垃圾书的最大贡献吧）。

「天才的土壤」，嗯，鲁迅说得好。不正应该是出版社的职志吗？我们却能向谁说去？其实我们也只是希望有一些好书造就一些资质不错的程序员而已。前一阵子才沸沸扬扬於印度程序员与中国程序员的比较，我们哪企望天才？不过就是希望培养一些扎实的人才而已。

看倌也许奇怪，书不好，侯捷为什麽不把矛头对准作者，却大骂出版社。哇勒，我早就抱着「得之我幸，不得我命」的卑微态度，不敢期望创作性中文好书。上面我说的，以及读者最痛心疾首的，是翻译书的低劣水平。人才济济的中国，怎麽可能找不到够格的译者？如果不是出版社的抢钱抢短心态，会造就出这一大批劣品吗？我能不怪罪出版社吗？

到头来，还是要靠自己。「计算机图书出版商的陷阱」一文最终是这麽说的：『记住，您花的是自己辛苦挣来的钱，所以千万不要浪费在没有用的东西上。对於出版了优秀图书的出版公司要有所回报。买他们的书，给他们写信，让他们知道你在想什麽，你需要什麽。』

良性循环
一个体系的建制，需要从底层到顶层的坚实构筑。不论是 C++, Java, .Net, OO, UML, Windows programming, Linux programming，每一个主题欲成就一个完整体系，都需要一大套书。拿C++/OOP 来说，就得涵盖语法语意的、物件模型的、专家经验的、设计样式（design patterns）的、入门的、进阶的，作为叁考工具的┅。拿 GP/STL 来说，就得有 GP 泛论型的、STL 源码剖析的、STL 应用大全的、STL 规格大全的、STL 组件设计的、其他泛型技术的┅。拿Java 来说，就得有语言核心的、物件导向的、多绪编程的、图形介面的、网路应用的┅。对生手而言，不先把底层的东西弄清楚就学习高层的抽象，必会成为空中楼阁，流于形式。对熟手而言，缺乏抽象思维，意味层次上的停滞。

写作、翻译、乃至於出版全体系好书，真的是一件需要目光长远、意志坚定、带点理想色彩的人，才做得起来的志业。

如果这样的人，这样的出版社，没有得到大家理念上和实质上的支持，谁会投入这种傻事？

我个人一向是高品质高价位的坚定信奉者。高品质高价位是生产者经营的最大诱因。因为努力做出了高品质，所以得享高价位带来的高利润，天经地义。否则谁要费心去做高品质？慈善家吗？傻瓜吗？

对於消费者，高价位当然令他不舒服。但是你应当思考是否物有所值，甚至物超所值。拿英文书为例，USD 49.95 一本的 The C++ Standard Library，或是 USD 49.95 一本的 Generic Programming and the STL，完全物超所值。当我了解这些书的价值，就算他们再贵两倍，我也要买。有人拼死吃河豚，我可是要拼命买好书。现实地说，眼下「知识经济」喊得震天响，好书带来的知识不正是赚钱工具吗？对赚钱工具小气，是不是和自己过不去？

下面是一封读者来信：

相较***无论是漫画作家、文学作家或是偶像歌星、影星的客观条件来比较， 在台湾，身为专业作家竟如此难为？有人可以连夜搭帐篷排队买票看演唱会，有人却可以论斤计两地讨论页数与书价高低。或许他们不知道，一本介绍C程式语言的入门书，在德国索价100 DM (约NT$2000)。 因此我的德国同事们购书前必定徵询意见或叁考书评。书价虽不低，但其读书风气仍不亚於***。

这里点出了一个重点：书价很高，於是大家慎选好书，重视书评。下面是另一封读者来信：

我是一名大陆的读者，同时也是一名计算机的初学者。我在网上看到网友都十分推崇您的着作及译作。知道您的作品《深入浅出MFC》第二版即将在内陆出版，我决定买这本书，并与华中科技大学出版社取了联系。从那里知道您今年还会在大陆出几本书，我非常高兴，但在知道了您对价格的看法後，又有些失望。

大陆与台湾的经济水平是不同的，作为普通的工薪阶层，购买力也是有限的。我们这里，各类图书中计算机类图书的价格是最高的，图书页码的最高位与书价的最高位基本相同 -- 700页的书，价格在70到80元之间，1000页以上的，价格在100元以上。这是目前大陆书价的大体情况。如果按您所说，350页，书价80元，在这里算是很高的价格了，这种价格的书，只能看，不能买。

"春蚕到死丝方尽，蜡炬成灰泪始干"，教师工作被我们看成很神圣的职业，燃烧自己，照亮别人。我想您出书的目的，也是想让更多渴望知识的人受益于它，少走弯路。作为读者，我们也希望能够看到更多更好的书。但是在一定历史时期内，购买力与价格应当有一个平衡，350页80元的价格确实太高了，如果能够降到60元以内，我相信大多数读者可以接受。

您的书的品质很高这是大家的共识，从价格上应当与其它书区别开来，但书价也不宜太高。名牌服装走高价位的路线，当然可以提高它的身价，显得它档次很高，但是太高的价格使它脱离了主要的消费群体，大多数人只能在口头上谈论它，却只有极少数的人会把它穿在身上。书籍与名牌服装不同，只有经过很多读者长时间的阅读之後，才能够证明它的价值，如果很多人都知道侯先生的书质量很好，但是却很少有人读过（因为价格问题），那岂不是一种悲哀。

我最不乐意看到「xxx 页的书，售价 xxx 元」这种观念。一本书的价值在内容，不在页数。真要这麽算，每本书我们都应该检视一下其字型大小、行距字距、硬拷图多寡、留白多寡 -- 因为这些都关系着页数。如果大家都接受页数和书价的固定比例，肯定会有大量浮滥的书跑出来（不就是现在的情况）。

不必这麽累。一本书值它的价，就买；不值它的价，就别买。很简单的逻辑。

我们难道能够拿着尺衡量一件亚曼尼用了多少码布，来决定它的价格吗？或是拿着尺衡量一张梵谷是几号，来决定它的价格？我能够说因为我画的绣球花比梵谷的鸢尾花大两倍，所以我应该卖他的两倍价？

买东西不能光看有形；那无形的往往更重要。买书不是买纸。正确价值观必须建立起来。

当然很有可能你认为买名牌服装或名画的人都是疯子。你要的只是布和框。那表示那些物品在你心中不值那个价。很好，你有你的评价，你有你的选择。

我不打算在「引喻」（例如名牌服装或名画）上面多着墨。引喻有顾此失彼的时候，笔战都是这样打起来的。各位知道我要强调的是什麽。

350页的书，不应该一定卖 80元，也不应该一定不卖 80 元。这要看350页的含金量有多少。况且我从没说过侯捷有 350页的书要卖 80元。但所有的可能都存在。350页可以是180元，也可以是80元，也可能 530 页连 18 元都不值。请不要再以页数做为书价的依据了。

教师的工作很神圣，但「燃烧自己，照亮别人」太沉重。「燃烧自己」，呵呵，说起来多麽容易，做起来多麽痛苦。某人的工作对众人有益，他会很开心。但你要他燃烧自己照亮别人，除非圣人，否则不干的。我很乐意照亮别人，却不想燃烧自己。燃烧自己，我只能照亮别人五年；把自己照顾好，我可以一辈子照亮别人。抬出大帽子，会让有能力写作好书的人畏惧不前。

请大家接受这样的观念吧：书的价值在内容，不在厚薄，不在页数。价值影响价格，价值带动价格。接受这样的观念，便是对好书的所有出力者致上敬意与实质支持。如果大家慎选好书，10 本垃圾书的价格支撑两三本高价（其实是适价）好书绰绰有馀。走编程这条路，谁手上没有 10 本 20 本垃圾书！当大家慎选好书，支持好书（尽管它价格较高），就会带动书评风气，带动优良写译风气。这对所有的人都好。不需有人燃烧自己，大家都被照亮了。

当然，高价位的薄书很可能带来盗印与影印的歪风。但无论如何，我是坚持己见不会退缩的。如果大环境真的无法提升，好书离开了，好人退出了，最後损失的是谁？

不论各位相信不信，侯捷企图以个人影响力（如果有的话）建立优良的技术写作大环境，对台湾如此，对大陆也是如此。「问渠安得清如许，为有源头活水来」，要让大家有更多好书可读，就要有源头活水注入；要有源头活水，就要有更多诱因吸引更多才能之士到技术写译领域来。更多的诱因是什麽？让他们知道，好作品可以突出，可以区隔（讲白了就是有好价格），不会牛骥同一皂，这就是一种诱因。不，这不算诱因，这根本是一种基本道理。

优质的书使读者受惠，优质书籍所带来的高报酬使作者、出版社受惠，并吸引更多优秀人才到这个领域。形成一个良性循环，大家都受惠。

另外我要建议大陆出版社，善用你们独特的「影印版」。台湾的计算机类翻译书，由於也是良窳不齐，窳多於良，曾有读者开玩笑建议，出版社取得授权後，不要译了，直接以原文出版，读者看得高兴，售价又得以大幅下降。想来这就是大陆的影印版（在台湾是不许的）。既然翻译书已到了千夫所指的地步，何不乾脆多多引进影印版？不是要抢短抢快吗？这个最快了，读者也多一种选择。

翻译出了什麽问题
计算机翻译书的一个大问题是，译者没有时间（或正确的心态，或足够的中文能力）将译稿一看再看，一改再改。中文有一个缺点，那就是名词本身表现不出复数，动词本身表现不出时态。多数时候这可能不是很重要，因而可以忽略。但某些时候它们占有关键地位，於是一个精准的英文句子，往往需要译者额外花很大的心力，才能精准地以中文表达出来，那麽译者就得有足够的时间和足够的中文能力。而唯有译者在专业技术上具备足够的素养，才能够看出某些隐微地方对理解之正确性有关键性影响。

英文里头的子句如果又臭又长，别说中国人，老外也得费一番手脚才看得懂。看看这个（C++ Primer 3/e, p730）：

[code..] where the conditional test if (this != &rhs)   prevents assigning a class object to itself. This is particularly inappropriate in a copy assignment operator that first frees a resource currently associated with the class in order to assign the resource associated with the class being copied.

我的译文是：

[code..] 其中的条件测试 if ( this != &rhs ) 避免将 class object 指派给自己，因为「自己指派给自己」这个动作，对於那种「先将目前系结於自己身上的资源释放掉，以便稍後将该份资源再系结於即将被拷贝的那个 object 身上」的 copy assignment 运算子而言，尤其不合适。

只需加几个引号，标示出子句，就好看多了。寻常一样窗前月，才有梅花便不同。如果没有引号辅助，你试译看看会是什麽样子。别对我说「根据教育部规范，上下引号只适用於强调专有名词或特殊语气┅」，规范是死的，人是活的呀。只要能够灵活而正确地表现出文意，就是好办法。小平同志不是说，管它黑猫白猫，会抓老鼠的就是好猫吗。阿波罗13号登月计划失败时，太空舱内的备用排气罩规格不符，地面控制中心要求宇航员必须想办法将方形罩子塞进圆形的排气管中，否则大家都得因为饱食二氧化碳而死於太空。这时候还想什麽规范？脑筋灵活点。

另一个中文表达的大缺点是：动名词不分。操作是名词（operation），也可以是动词（operate）；实现是名词（implementation），也可以是动词（implement）；叁考是名词（reference），也可以是动词（refer）；请求是名词（request），也可以是动词（request）；委托是名词（delegation），也可以是动词（delegate）。当动词名词混杂一起的时候，就造成阅读上的错乱。於是你可以看到这样的句子（取材自《设计模式》p14，李英军等译，机械工业出版社）。请诸位先看原译，能否就中文语句结构分析出其大致意思：

(1)原译：只有当委托使设计比较简单而不是更复杂时，它才是好的选择。

(1)侯译：只有当「委托方式」简化了设计，它才是一个好的选择。

(1)原文：Delegation is a good design choice only when it simplifies more than it complicates.

(2)原译：委托方式为了得到同样的效果，接受请求的对象将自己传给被委托者（代理人），使被委托的操作可以引用接受请求的对象。

(2)侯译：为了以「委托方式」获得相同效果，「请托（request）受理者」将自己传给被委托人，使自己得以让「被委托之操作行为」取用。

(2)原文：To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver.

我没有一别苗头之意。我的译法不见得最高明。况且翻译一整本书所需的各种前後呼应的考量，远比光译一两个句子复杂许多。只是既然我提出了问题，我总要提出自己的解法，给大家叁考评量。对於机械工业出版社愿意出版这样一本经典，李英军先生等人愿意翻译这样一本高阶而吃力不讨好的书，我是带有敬意的。

另一个翻译上的问题就是大家往往在计算机类书中硬套一般字典查来的词汇，没人敢突围。要知道，一般字典并未考量电脑技术，更不可能考虑到上下文（context）。太多人抱着少做少错，不做不错的心理，一昧紧跟字典，不敢变动，才会造成目前许多译词不够理想，却动弹不得。我印象最深刻的是这几个字：

instance：台湾和大陆均有不少人译为「实例」。这个「例」字根本不好。台湾甚至有人译为「案例」，更不妥当。为什麽这麽译，因为字典查来的现成词汇是这样。所谓 instance 就是根据某个东西（可能是实物，可能是某种表述）产生出来的一份实际物体。我认为译为「实体」是很合适的。根据 class 产生出来的便是object实体，根据 class template 产生出来的则是class 实体，根据 function template 产生出来的是function 实体。根据可执行档（executable files）产生出来的，则是一份 process 实体。

paradigm：台湾常译为「典范」。为什麽？喔，字典查来的现成词汇。有时候这样译有点道理，例如 paradigm shift 叫做「典范移转」。问题是，何谓「典范移转」？很难望文生义是吧。把 generic paradigm 译为泛型典范，更是令人不知所以。我们日常用语里也有「典范」一词，我们会说某某人是国家社会的典范，那和计算机术语里头的 paradigm 根本不是同一个意思。根据 paradigm 在计算机术语中的实际意义，我把它译为「思维模式」 ─ 典型的、根本的思维模式。

读者来了这样一封信：

我向您讨教一个翻译风格的问题。正如您所说，英文技术书籍最难在长句子，因为英文的句式组合形式比中文大大丰富，理解起来已经费力，翻译成顺口的中文更难。我有时遇到这种句型，切分组合，翻来覆去掂量，还是觉得中文不忍卒读。您认为此时 (1) 我可不可以放弃 "信" 而求 "达"，也就是说略掉部份句子成份以保全译句的通顺？还是 (2) 务求将原义表达出来，宁可中文句子不顺畅也在所不惜？更有甚者，有时 (3) 某些句子无关宏旨，却异常难译，可不可以乾脆略过不译？您的看法是什麽？

（各位有没有注意到，这位读者的中文很好。「切分组合，反覆掂量」这几个字用得多精简传神）我的看法是，译者有权利也有义务通权达变，但也必须有这份能耐才行。因此你的第一个问题我认为可以，你的第二个问题我认为不可以。你的第三个问题我认为可以，但需谨慎为之，莫因译者本身水平，牺牲了某些东西。

科技翻译应该务求义译而非字译。信与达，应从整个句子或甚至整个段落来看，不是从一个个单字来看。技术文章和文学多有不同，译者最重要的任务是正确传达知识，并尽量减少读者的吸收困难。

到底弹性的底限在哪里？我这麽认为，译者於技术层次上愈有把握，便享有愈大的弹性。只要技术层次够，有把握正确了解并传达了原作者要表达的技术，那麽，文字上不必字字拘泥。

中文在科技表达中并非一无是处。中文有一个优点，就是资讯密度高，很多时候精简漂亮的一行中文，可以表达出「子句夹带子句再夹带子句」的三行冗长英文。中文有优美的词藻与取之不尽用之不竭的典故、成语、俗谚，如果善用它们，冰冷的技术文字一下子就能有阅读的乐趣。一本烂译本，会让读者诘屈聱牙，痛苦至极；但是一本好译本，能使人如沐春风。

容我说一句，正确的心态、足够的时间、充裕的中文表达能力、水平以上的专业素养，是造就好译本的基本元素。现今情况如何？话说回头，好译者的报酬几何？你愿意多花点钱表示你对他们的付出的认同吗？

健康的选书心态
以下谈到选书的心态和作学问的态度，由於都以读者来信展开讨论，因此避免不了提到我写的《深入浅出MFC》。我要谈的问题，其实不局限於某一本书，或某一种技术。就像这篇文章先前举的许多例子一样，都是可以放大来看的。

读者修书一封如下：

2个星期前好不容易读完了您的大作，让我对MFC的认识多了不少，不过一点遗憾的是从您的书里并不能学到如何写一个具体的程序，仅仅是明白了MFC的'包装技术'。本来我还以为又上当了呢 因为我买这本书的目的就是要学习用MFC来做程序的...一个偶然的机遇让我得到了 Jeff Prosise的《programming windows with MFC》，这才发现老师您的书是多麽的重要，假如没有您的《深入浅出MFC》我又怎麽可能programming with MFC呢？...您的书救我于水深火热之中，带领我冲破MFC的条条封锁线。

虽然这位读者最终对侯捷和侯捷的书以感谢和赞美作收，但我颇有感慨。

读者往往以最直观的态度来审视一本书的价值，以最直接的方式来表达他的爱憎。但不能凡是不需要的，一律视为灌水；凡不符合需求的，一律视为欺骗。这不是一种健康的选书态度。即使你最後并没有发现《深入浅出MFC》「是多麽的重要，救我于水深火热之中，带领我冲破MFC的条条封锁线」，这本书又何尝在书名或内容欺骗过你，使你「以为又上当了呢」。再者「我买这本书的目的就是要学习用MFC来做程序的」，可是你若连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，能写出多好的程序？

我不是责怪这位读者，只是这封来信代表某些现象，让我心有感慨。下面是另一种偏激：

您的书我觉得有些无用的原理讲的太多了! 你所写的并不是真正的教人怎麽用VC,而是教人VC运做是怎麽样进行的! 其实很多读者真正关心的问题并不是在这里! 而是在怎麽对用VC设计出真正出色的程序!

读者永远只想要看自己想看的内容，这一点很自然。但是你不想看到的东西并非就是「无用」，它对别人可能「很有用」。再说，连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，我不知道你能写出什麽「出色的程序」。只要出一点差错，你连除错的能力都没有。开车是很简单的，开车上路遇到各种突发状况而能应付并排除障碍，才是困难的地方，才是技术的表现。

下面是两封台湾读者的意见，有点年代了。当然我必得先说明，抱持这种态度的读者，比例大约在百分之零点零一。

读者意见一

这本书包装太厚。不该有的东东太多，附录A所列的无责任书评，在我想来也是多馀。因为这篇书评在RUN!PC早有提及，後来也出了无责任书评第三集，因此实在没有这个必要。想来是侯先生要增加书的厚度，有以致也。

读者意见二

书评不应该放在这本书里吧! 因为这些东西而让书太厚实在有点┅这些灌水的东西共计有：
(a)1-16页的读者来函：共16页
(b)超长的序，嗯，这应该没有关系
(c)843-872页的无责任书评：共30页(其实里面有一些发人省思的东西，还好)
(d)873-914页的Scribble原始码：共42页(这最严重，几乎没必要的东西)
(e)915-920页的VC范例程式一览：共6页(很可惜，如果再多加发挥的话很有用，
但是侯Sir只是列个标题，连说明都是英文，和看Help档没什麽差别)
共计：94页

不是我无聊找碴，您可曾看到有哪本书有将近一百页的赘肉?更别题书中动不动就列出四五页的原始码了。这些在光碟上都有，何必浪费纸张? 不过消掉这些赘肉，这本书还是有它的价值┅至於书中缺少的部份，我认为要看您如何去定位这本书。
总不能要求一本书把所有Program的东西讲完吧! 以探讨MFC的内部而言，本书没什麽好批评的了。总而言之，这本书该不该买，我想还是肯定的。但是如果书能瘦点、售价能低点，那就更好了。

说来说去，原来是为了「如果书能瘦点、售价能低点那就更好了」。这便是页数和售价牵扯观念下的可怜受害者，他们扭曲了书籍的价值，也严重扭曲了自己该有的正确价值观。如果我告诉这些读者，少掉那100页的所谓「赘肉」，售价一样是 NTD 860，恐怕他们又要对这些「赘肉」热情拥抱来一个亲亲了。真的是这样，这本书是先确定价格，最後为了给读者更多资讯和更大的方便，我才加上那些「赘肉」的。

这一类读者，站在敌对的立场，看待出版社和作者，幻想每一个人都在觊觎他的钱包，并且认为对他无实质帮助的每一页（可能只是因为他已看过）都是被刻意灌水的结果，都是为了欺骗他的钞票。这样的读者在杯弓蛇影的压力之下，忘记了没有任何一本书是为个人量身打造的，也忘记了其他人可能有不同的需求，完全以自我为中心。

这一类不成熟的读者，实在是当前劣品充斥下的牺牲者。老实说我个人并不喜欢他们成为我的读者。只是，读者有选择作者的权利，作者却没有选择读者的机会。

正确的作学问态度
前面两篇来信透露出一个疑惑，《深入浅出MFC》是不是一本对VC编程有帮助的书。我不是要在这里夹带推荐该书（相信我，我不需要如此），而是想透过MFC与VC的关系，引申谈谈作学问的态度。如果「作学问」太高远了，那我们来谈谈「学习」的态度吧。

以下是一封读者来函：

我有个疑惑，想请你帮助。我们今天学C/C++，明天学MFC，OWL(如果流行的话)
後天学C#，JAVA...如果 WINDOW 被 X WINDOW 淘汰，岂不是都要从头学过？有没有必要把一切搞得如此精通？同样的目的，为什麽不用更方便简单的快速RAD开发工具？而非要以钻研繁杂作为乐趣？和体现水平？是否搞错了方向和目标？我认为这正是目前大陆（台湾我不了解）软件开发的一个错误的方向。

所有同质的技术都有累积性与共通性。信中提到的三组东西：MFC, OWL, 或是 Windows, X Window, 或是 C++, Java, C#, 都有类似性与共通性。技术是会累积的，有了某种经验，学习新技术会快很多。经验愈多，学习愈快。所以我常喜欢说「触类旁通」。如果每种技术都得从新学习，大家三五年就得归零一次，人类世界就不会在 20 世纪像爆炸似地进步这麽快。

「有没有必要把一切搞得如此精通？」我的回答是：看个人需求与定位。基础知识的精通，是做为应用的一种过程与手段，而不是目的。如果你不需要通过这样的过程，就可以把你要做的事情做得很好，那麽当然你可以跳过这个过程。我所知道的是，许多许多人必须先有这样的过程，才能够良好达成期望目标。我自己也需要通过这样的过程（否则写不出这样的书）。这不是你所谓的「钻研繁杂」或「体现水平」。

既然信中提到RAD，我也谈谈我的看法。我曾经写过一篇文章，把RAD喻为「匹夫无罪，怀璧其罪」（见侯捷网站 1999/01/26 怀璧其罪 RAD），建议各位看看。我很赞成使用RAD。我书写MFC书籍，探讨MFC技术，但从来没有认为它最好，或不好，我只是要帮助那麽多使用MFC的人。和Bjarne 的态度一样，我对诸如此类的工具评比活动一点兴趣都没有。我乐意当一名观众，但从来不评比（应该可以说，也没有能力评比）。

RAD 的情况，可以拿汽车做比喻。现今谁开车还需要知道齿轮箱、传动轴、离合器、引擎点火原理、火星塞呢？但是满街开车人谁又能够表演360度大回旋？要到达「车手」的程度，就必须对车子的原理有相当程度的了解。同样是开车，洗拿（F1方程式冠军车手）和侯捷两人发挥车辆功能的程度，绝对有天壤之别。我认识的所有惯使RAD 的高手，无一不是有底层深厚功力。以RAD始，以RAD终，断不能在技术上有所太大长进。你的生涯将是空白的五线谱，没有高音，没有低音，永远的水平┅。

RAD是要用的，有好工具不用，和自己过不去。但是使用RAD的同时，对底层做更多的了解才有助於在某种情况下脱困或自助。这和 STL 的运用也一样。会用STL，是一种档次。对STL原理有所了解，又是一个档次。追踪过STL源码，又是一个档次。第三种档次的人用起 STL 来，虎虎生风之势绝非第一档次的人能够望其项背。

学习某种工具，及其背後代表的某种技术，究竟要钻研到什麽深度？唔，答案视你想扮演什麽角色而定。「F1方程式车手」和「半夜三点才敢上台北大马路的用车人」之间，有许多许多的层次，你自己定位自己。

有些人绝对拥护RAD，有些人又重新反省RAD。下面是另一封信：

我原本是一个一天到晚使用RAD工具的人...但是历经了三个版本之後，我有一种被骗的感觉，因为处在这个环境中，似乎是投身在别人设好的一个圈套里！这种东西会让人对於『了解 OS 内部运作以及各种规范与协定的基础层面』的欲望慢慢减低至零。今天为了突破某一个元件的限制而自己写了一个元件，明天新版RAD内附元件就出现了比自己写得还要好的东西。到了最後，自己不想写，只想等别人写给你
；要是别人不写，你就彻头彻尾地丧失了一项能力...(天晓得要等到何年何月)，要不然就是官方给的元件功能少东少西。不只这些！最让我受不了的是，我竟然发现：程式用这种方式去写，简直就比用Office 还要简单，深入的思考几乎是零...。

我在「怀璧其罪 RAD」一文中是这麽回答的：

1. RAD 并非罪恶，而是优点。要怎麽用它则是你自己的问题。我有两位朋友是 Delphi 专家，他们可以使用 Delphi 做任何事情，没有任何你想像中 RAD「该有」的限制。

2. 果真能够「写一个程式，比使用 Office 还要简单，深入的思考几乎是零」，并不是坏事。大家都能够随手写个小程式解决手边几个小问题，是为component software 以及 RAD 的大贡献。但你的形容太夸张了，目前的 RAD 还不至於美好若此，总还需要一些程式逻辑和程式语言的基本训练。真到了你说的那一天，我觉得是件好事而不是坏事。只不过，那样子完成的程式，都需藉助现成的元件。如果要突破现成的框框，就得有更深的功力。无论如何，RAD 不会是你的绊脚石。

这类话题很难一言以蔽之。总之，优秀的技术者一定需要一个向下沉淀的历练，通过了这层历练，有了扎实的基础，就可以向上浮升，开始以抽象的思考，抽象的语言、快速开发工具来进行高层次的开发工作。这时候运用 RAD 工具，当能如虎添翼。

所谓百炼成钢；钢的形成，是将铁块不断锤打，不断回火，不断淬炼。做为一个程式员，本身技能的层次，和回火淬炼的次数有密切关系。

让我们再回头谈谈基础建设。很多资讯科系在学学生对学校所开的课程，非常不服气，非常不屑，认为对编程能力一点帮助也没有。首先我要说，编程、软件开发并不是资讯系学生的唯一出路。资讯领域何其广泛，编程只是其中小小的一支而已（但对就业市场而言则是大大的一脉）。其次我要说，基础理论课程并非对你的编程一无是处 ─ 不是无用，只是未到用时。有些科目的影响非常直接而深远，例如对编程最重要的两门课：资料结构（data structure）和演算法（algorithm），这两门课对逻辑思考与实现能力的训练，有关键性的价值。没有这两门课做底，任你 C/C++/Java 多强多行，也写不出个好程式。其他基础理论课程也都各有用途，会不会在你未来的编程生涯中带来帮助，那得看你编哪一种程。就业与学校所学，不必然会发生关系，不必然不会发生关系。

编程能力强的年轻同学，容易孳生一种趾高气扬的恶习，看这不顺眼，看那不顺眼，教授都老朽，同学都可笑。问他为什麽，哦，因为「他们的编程功力都不如我」。可笑的正是你自己呀。

编程实力的培养其实很容易的。我所谓容易，是指不需借助外力，纯粹自修就几乎可以做到。再没有比这更幸运的事了。当然你的进修必须按部就班（在我的专长范围内，我写了很多让你前进时有所依循的文章，都在侯捷网站上）。任何高深的理论，只要实际操作过都可以霍然理解，编程的实作又有什麽难的。数本好书，一部电脑，一些必要的工具，全部搞定，只欠一股「头悬梁锥刺股」的苦读精神。实力进展到一个阶段後，我非常鼓励你追踪名家源码（有人指导更好）。司马相如说：能读千赋则善赋，能观千剑则善剑。侯捷说：读过千赋亦能赋，观过千剑亦能剑。

最後我还要说，学校（尤其大学）原本不是职训所。但是关於人格的培养，思想的启迪，视野的开拓，现今言之，恐怕是陈义过高，没人爱听了。

学校肯定有学校的缺失。其一是课程太过理论，高来高去。以大学生的程度而言，太过抽象的东西他们是没有能力接受的。但是要化抽象为具象，化繁为简，可得有非常深厚的实力才行。其二是教材、教具、教师太过陈旧，跟不上时代。我印象最深刻的是，台湾BBS时常有学生问 Turbo C 3.0 上的问题。我的妈呀，C++ Standard 都出来两年了，学校还在用TC3.0。倒不是说一定要追最新最炫的工具或产品，但是TC3.0 距离 C++ Standard，有月球到地球的距离吧。用这个编译器，可想而知老师教的是什麽内容，可想而知老师本身跟上外界脉动的程度。如果新工具新产品都很贵，顾及学校经费，我们也能体谅。可 Borland C++ 5.5, GNU C++ 2.96, TAI C++ 都是可以免费下载或限期试用的呀。它们对 C++ Standard 的实现，比TC3.0 好太多太多了。

这就涉及学校教育里头最重要的关键：师资。说句实在话，大学里头有不少老师，书是念得很棒，就是没有实作经验，更没有业界经验。因循苟且之念一动，万年教材一摊，同学们就只有自求多福。

自救之道当然有：你必须更勤奋。勤奋看书，勤奋发问。勤奋搜寻好的导师和好的读物。或许天道酬勤，就让你碰上一个传道授业解惑的贵人，就让你知道一本必读的经典，并且就让你找到它。

说到勤奋发问，让我发出本文的最後一声感叹做为结束。台湾大学生在「表达能力」这一点，程度普遍低下幼稚。能够条理分明把自己的意思表达清楚的，十分罕见。反映出来的，就是怯怯懦懦，理不直而气不壮。私底下声若洪钟，要他站起来公开表示意见，却如细蚊之嗡嗡。不论口语或文字，用词普遍地「俗」。大陆情况，就我的印象，以及我收到的读者来信，感觉好很多。以前台湾的说法是，因为大陆斗争厉害，人人得有一口利嘴以求自保。但文革已过数十年，我看大家的表达能力普遍还是很不错，是不是求学阶段中曾经特别重视这个？

发问的能力影响学习甚巨。善问者使人继其声，善教者使人承其志。我常自诩为一名善教者，但如课堂上兼能有一名善问者，高潮迭起，全班受惠。

一、 工具篇JDK (Java Development Kit)

JDK是整个Java的核心，包括了Java运行环境（Java Runtime Envirnment），一堆Java工具和Java基础的类库(rt.jar)。不论什么Java应用服务器实质都是内置了某个版本的JDK。因此掌握JDK是学好Java的第一步。最主流的JDK是Sun公司发布的JDK，除了Sun之外，还有很多公司和组织都开发了自己的JDK，例如IBM公司开发的JDK，BEA公司的Jrocket，还有GNU组织开发的JDK等等。其中IBM的JDK包含的JVM（Java Virtual Machine）运行效率要比Sun JDK包含的JVM高出许多。而专门运行在x86平台的Jrocket在服务端运行效率也要比Sun JDK好很多。但不管怎么说，我们还是需要先把Sun JDK掌握好。

1、 JDK的下载和安装

JDK又叫做J2SE（Java2 SDK Standard Edition），可以从Sun的Java网站上下载到，http://java.sun.com/j2se/downloads.html ，JDK当前最新的版本是J2SDK1.4.2，建议下载该版本的JDK，下载页面在这里：http://java.sun.com/j2se/1.4.2/download.html。下载好的JDK是一个可执行安装程序，默认安装完毕后会在C:\Program Files\Java\目录下安装一套JRE（供浏览器来使用），在C:\j2sdk1.4.2下安装一套JDK（也包括一套JRE）。然后我们需要在环境变量PATH的最前面增加java的路径C:\j2sdk1.4.2\bin。这样JDK就安装好了。

2、 JDK的命令工具

JDK的最重要命令行工具：


java： 启动JVM执行class
javac： Java编译器
jar： Java打包工具
javadoc： Java文档生成器




这些命令行必须要非常非常熟悉，对于每个参数都要很精通才行。对于这些命令的学习，JDK Documentation上有详细的文档。

二、 JDK Documentation

Documentation在JDK的下载页面也有下载连接，建议同时下载Documentation。Documentation是最最重要的编程手册，涵盖了整个Java所有方面的内容的描述。可以这样说，学习Java编程，大部分时间都是花在看这个Documentation上面的。我是随身携带的，写Java代码的时候，随时查看，须臾不离手。

三、 应用服务器(App Server)



App Server是运行Java企业组件的平台，构成了应用软件的主要运行环境。当前主流的App Server是BEA公司的Weblogic Server和IBM公司的Websphere以及免费的Jboss，选择其中一个进行学习就可以了，个人推荐Weblogic，因为它的体系结构更加干净，开发和部署更加方便，是Java企业软件开发人员首选的开发平台。下面简要介绍几种常用的App Server：

1、 Tomcat

Tomcat严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，数据库连接池，用户事务处理等等。Tomcat被非常广泛的应用在中小规模的Java Web应用中，因此本文做一点下载、安装和配置Tomcat的介绍：

Tomcat是Apache组织下Jakarta项目下的一个子项目，它的主网站是：http://jakarta.apache.org/tomcat/ ，Tomcat最新版本是Tomcat4.1.27，软件下载的连接是：http://www.apache.org/dist/jakarta/tomcat-4/binaries/ 。

下载Tomcat既可以直接下载zip包，也可以下载exe安装包（个人建议zip更干净些），不管哪种情况，下载完毕安装好以后（zip直接解压缩就可以了）。需要设置两个环境变量：


JAVA_HOME=C:\j2sdk1.4.2
CATALINA_HOME=D:\tomcat4 (你的Tomcat安装目录)




这样就安装好了，启动Tomcat运行CATALINA_HOME\bin\startup.bat，关闭Tomcat运行shutdown.bat脚本。Tomcat启动以后，默认使用8080端口，因此可以用浏览器访问http://localhost:8080来测试Tomcat是否正常启动。



Tomcat提供了两个Web界面的管理工具，URL分别是：

http://localhost:8080/admin/index.jsp

http://localhost:8080/manager/html

在启用这两个管理工具之前，先需要手工配置一下管理员用户和口令。用一个文本工具打开CATALINA_HOME\conf\tomcat-users.xml这个文件，加入如下几行：


<role rolename="manager"/>
<role rolename="admin"/>
<user username="robbin" password="12345678" roles="admin,manager,tomcat"/>




这样用户“robbin”就具备了超级管理员权限。重新启动Tomcat以后，你就可以使用该用户来登陆如上的两个管理工具，通过Web方式进行Tomcat的配置和管理了。

2、 BEA Weblogic

Weblogic可以到BEA的网站上免费注册之后下载到最新的Weblogic8.1企业版，License可以免费使用1年时间，其实这已经完全足够了。Weblogic的下载连接：http://commerce.bea.com/index.jsp，.../edocs.bea.com/ 。

3、 IBM Webshpere

Websphere同样可以下载到免费的试用版本，到IBM的developerWorks网站可以看到Websphere试用产品的下载和相关的Websphere的资料，developerWorks中文网站的连接是：http://www-900.ibm.com/developerWorks/cn/wsdd/ ，Websphere的下载连接：http://www7b.software.ibm.com/wsdd/...WASsupport.html 。

4、 Jboss

Jboss是免费开源的App Server，可以免费的从Jboss网站下载：http://www.jboss.org/index.html，然...n.com/idea.html

四、 Java应用的运行环境

Java的应用可以简单分为以下几个方面：

1、 Java的桌面应用

桌面应用一般仅仅需要JRE的支持就足够了。



2、 Java Web应用

Java的Web应用至少需要安装JDK和一个web容器（例如Tomcat），以及一个多用户数据库，Web应用至少分为三层：

Browser层：浏览器显示用户页面

Web层：运行Servlet/JSP

DB层：后端数据库，向Java程序提供数据访问服务



3、 Java企业级应用

企业级应用比较复杂，可以扩展到n层，最简单情况会分为4层：

Browser层：浏览器显示用户页面

Client层：Java客户端图形程序（或者嵌入式设备的程序）直接和Web层或者EJB层交互

Web层：运行Servlet/JSP

EJB层：运行EJB，完成业务逻辑运算

DB层：后端数据库，向Java程序提供数据访问服务



4、 Java嵌入式应用

Java嵌入式应用是一个方兴未艾的领域，从事嵌入式开发，需要从Sun下载J2ME开发包，J2ME包含了嵌入式设备专用虚拟机KVM，和普通的JDK中包含的JVM有所不同。另外还需要到特定的嵌入式厂商那里下载模拟器。  


书籍篇

学习一门新的知识，不可能指望只看一本，或者两本书就能够完全掌握。需要有一个循序渐进的阅读过程。我推荐Oreilly出版的Java系列书籍。

在这里我只想补充一点看法，很多人学习Java是从《Thinking in Java》这本书入手的，但是我认为这本书是不适合初学者的。我认为正确的使用这本书的方法应该是作为辅助的读物。《Thinking in Java》并不是在完整的介绍Java的整个体系，而是一种跳跃式的写作方法，是一种类似tips的方法来对Java很多知识点进行了深入的分析和解释。

对于初学者来说，最好是找一本Java入门的书籍，但是比较完整的循序的介绍Java的语法，面向对象的特性，核心类库等等，在看这本书的同时，可以同步来看《Thinking in Java》，来加深对Java的理解和原理的运用，同时又可以完整的了解Java的整个体系。

对于Java的入门书籍，蔡学镛推荐的是Oreilly的《Exploring Java, 2nd Edition》 或者《Java in a Nutshell,2nd Edition（针对C++背景）》，我并没有看过这两本书。其实我觉得电子工业出版社的《Java 2编程详解》或者《Java 2从入门到精通》就很不错。

在所有的Java书籍当中，其实最最有用的，并不是O'reilly的 Java Serials，真正最最有用处是JDK的Documentation！几乎你想获得的所有的知识在Documentation里面全部都有，其中最主要的部分当然是Java基础类库的API文档，是按照package来组织的，对于每一个class都有详细的解释，它的继承关系，是否实现了某个接口，通常用在哪些场合，还可以查到它所有的public的属性和方法，每个属性的解释，意义，每个方法的用途，调用的参数，参数的意义，返回值的类型，以及方法可能抛出的异常等等。

可以这样来说，所有关于Java编程方面的书籍其实都不过是在用比较通俗易懂的语言，和良好的组织方式来介绍Documentation里面的某个package里面包含的一些类的用法而已。所以万变不离其宗，如果你有足够的能力来直接通过Documentation来学习Java的类库，那么基本上就不需要看其他的书籍了。除此之外，Documentation也是编程必备的手册，我的桌面上有三个Documentation的快捷方式，分别是J2SDK1.4.1的Documentation，Servlet2.3的Documentation和J2SDKEE1.3.1的Documentation。有了这个三个Documentation，什么其他的书籍都不需要了。

对于Java Web 编程来说，最核心的是要熟悉和掌握HTTP协议，这个就和Java无关了，在熟悉HTTP协议之后，就需要熟悉Java的实现HTTP协议的类库，也就是Servlet API，所以最重要的东西就是Servlet API。当然对于初学者而言，直接通过Servlet API来学习Web编程有很大的难度，我推荐O'reilly的《Java Server Pages 》这本书来学习Web 编程。

EJB的书籍当中，《Enterprise JavaBeans, 2nd Edition》是一本很不错的书， EJB的学习门槛是比较高，入门很难，但是这本书完全降低了学习的难度，特别重要的一点是，EJB的学习需要结合一种App Server的具体实现，所以在学习EJB的同时，必须同步的学习某种App Server，而这本书相关的出了三本书，分别是Weblogic6.1，Websphere4.0和JBoss3.0上面部署书中例子的实做。真是既有理论，又有实践。在学习EJB的同时，可以边看边做，EJB的学习会变得很轻松。

但是这本书也有一个问题，就是版本比较旧，主要讲EJB1.1规范和部分EJB2.0的规范。而Ed Roman写的《Mastering EJB 2.0》这本书完全是根据EJB2.0规范写的，深入浅出，覆盖了EJB编程的各个方面，并且还有很多编程经验tips，也是学习EJB非常推荐的书籍之一。

如果是结合Weblogic来学习J2EE的话，《J2EE应用与BEA Weblogic Server》绝对是首选读物，虽然是讲述的Weblogic6.0，仍然值得购买，这本书是BEA官方推荐的教材，作者也是BEA公司的工程师。现在中文版已经随处可见了。这本书结合Weblogic介绍了J2EE各个方面的技术在Weblogic平台上的开发和部署，实践指导意义非常强。

在掌握了Java平台基础知识和J2EE方面的知识以后，更进一步的是学习如何运用OO的方法进行软件的设计，那么就一定要学习“设计模式”。Sun公司出版了一本《J2EE核心模式》，是每个开发Java企业平台软件的架构师必备的书籍。这本书全面的介绍了J2EE体系架构的各种设计模式，是设计师的必读书籍。

过程篇

每个人的学习方法是不同的，一个人的方法不见得适合另一个人，我只能是谈自己的学习方法。因为我学习Java是完全自学的，从来没有问过别人，所以学习的过程基本上完全是自己摸索出来的。我也不知道这种方法是否是比较好的方法，只能给大家提供一点参考了。

学习Java的第一步是安装好JDK，写一个Hello World，? 其实JDK的学习没有那么简单，关于JDK有两个问题是很容易一直困扰Java程序员的地方：一个是CLASSPATH的问题，其实从原理上来说，是要搞清楚JRE的ClassLoader是如何加载Class的；另一个问题是package和import问题，如何来寻找类的路径问题。把这两个问题摸索清楚了，就扫除了学习Java和使用JDK的最大障碍。推荐看一下王森的《Java深度历险》，对这两个问题进行了深入的探讨。

第二步是学习Java的语法。Java的语法是类C++的，基本上主流的编程语言不是类C，就是类C++的，没有什么新东西，所以语法的学习，大概就是半天的时间足够了。唯一需要注意的是有几个不容易搞清楚的关键字的用法，public，protected，private，static，什么时候用，为什么要用，怎么用，这可能需要有人来指点一下，我当初是完全自己琢磨出来的，花了很久的时间。不过后来我看到《Thinking in Java》这本书上面是讲了这些概念的。

第三步是学习Java的面向对象的编程语言的特性的地方。比如继承，构造器，抽象类，接口，方法的多态，重载，覆盖，Java的异常处理机制。对于一个没有面向对象语言背景的人来说，我觉得这个过程需要花很长很长时间，因为学习Java之前没有C++的经验，只有C的经验，我是大概花了一个月左右吧，才彻底把这些概念都搞清楚，把书上面的例子反复的揣摩，修改，尝试，把那几章内容反复的看过来，看过去，看了不下5遍，才彻底领悟了。不过我想如果有C++经验的话，应该一两天时间足够了。那么在这个过程中，可以多看看《Thinking in Java》这本书，对面向对象的讲解非常透彻。可惜的是我学习的时候，并没有看到这本书，所以自己花了大量的时间，通过自己的尝试和揣摩来学会的。

第四步就是开始熟悉Java的类库。Java的基础类库其实就是JDK安装目录下面jre\lib\rt.jar这个包。学习基础类库就是学习rt.jar。基础类库里面的类非常非常多。据说有3000多个，我没有统计过。但是真正对于我们来说最核心的只有4个，分别是


java.lang.*;
java.io.*;
java.util.*;
java.sql.*;




这四个包的学习，每个包的学习都可以写成一本厚厚的教材，而O'reilly也确实是这样做的。我觉得如果时间比较紧，是不可能通过读四本书来学习。我觉得比较好的学习方法是这样的：



首先要通读整个package的框架，了解整个package的class，interface，exception的构成，最好是能够找到介绍整个包框架的文章。这些专门介绍包的书籍的前几章应该就是这些总体的框架内容介绍。

对包整体框架的把握并不是要熟悉每个类的用法，记住它有哪些属性，方法。想记也记不住的。而是要知道包有哪些方面的类构成的，这些类的用途是什么，最核心的几个类分别是完成什么功能的。我在给人培训的时候一般是一次课讲一个包，所以不可能详细的介绍每个类的用法，但是我反复强调，我给你们讲这些包的不是要告诉你们类的方法是怎么调用的，也不要求你们记住类的方法调用，而是要你们了解，Java给我们提供了哪些类，每个类是用在什么场合，当我遇到问题的时候，我知道哪个类，或者哪几个类的组合可以解决我的问题，That'all！，当我们具体写程序的时候，只要你知道该用哪个类来完成你的工作就足够了。编码的时候，具体的方法调用，是边写代码，边查Documentation，所有的东西都在Documentation里面，不要求你一定记住，实际你也记不住3000多个类的总共将近10万个方法调用。所以对每个包的总体框架的把握就变得极为重要。



第五步，通过上面的学习，如果学的比较扎实的话，就打好了Java的基础了，剩下要做的工作是扫清Documentation里面除了上面4个包之外的其他一些比较有用处的类。相信进展到这一步，Java的自学能力已经被培养出来了，可以到了直接学习Documentation的水平了。除了要做GUI编程之外，JDK里面其他会有用处的包是这些：


java.text.*;
java.net.*;
javax.naming.*;






这些包里面真正用的比较多的类其实很少，只有几个，所以不需要花很多时间。

第六步，Java Web 编程

Web编程的核心是HTTP协议，HTTP协议和Java无关，如果不熟悉HTTP协议的话，虽然也可以学好Servlet/JSP编程，但是达不到举一反三，一通百通的境界。所以HTTP协议的学习是必备的。如果熟悉了HTTP协议的话，又有了Java编程的良好的基础，学习Servlet/JSP简直易如反掌，我学习Servlet/JSP就用了不到一周的时间，然后就开始用JSP来做项目了。



在Servlet/JSP的学习中，重头仍然是Servlet Documentation。Servlet API最常用的类很少，花比较少的时间就可以掌握了。把这些类都看一遍，多写几个例子试试。Servlet/JSP编程本质就是在反复调用这些类来通过HTTP协议在Web Server和Brower之间交谈。另外对JSP，还需要熟悉几个常用JSP的标记，具体的写法记不住的话，临时查就是了。



此外Java Web编程学习的重点要放在Web Application的设计模式上，如何进行业务逻辑的分析，并且进行合理的设计，按照MVC设计模式的要求，运用Servlet和JSP分别完成不同的逻辑层，掌握如何在Servlet和JSP之间进行流程的控制和数据的共享，以及Web Application应该如何配置和部署。


第七步，J2EE编程

以上的学习过程如果是比较顺利的话，进行到这一步，难度又陡然提高。因为上面的知识内容都是只涉及一个方面，而像EJB，JMS，JTA等核心的J2EE规范往往是几种Java技术的综合运用的结晶，所以掌握起来难度比较大。

首先一定要学习好JNDI，JNDI是App Server定位服务器资源（EJB组件，Datasouce，JMS）查找方法，如果对JNDI不熟悉的话，EJB，JMS这些东西几乎学不下去。JNDI其实就是javax.naming.*这个包，运用起来很简单。难点在于服务器资源文件的配置。对于服务器资源文件的配置，就需要看看专门的文档规范了，比如web.xml的写法，ejb-jar.xml的写法等等。针对每种不同的App Server，还有自己的服务资源配置文件，也是需要熟悉的。

然后可以学习JTA，主要是要理解JTA对于事务的控制的方法，以及该在什么场合使用JTA。这里可以简单的举个例子，我们知道一般情况可以对于一个数据库连接进行事务控制(conn.setAutoCommit(false),....,conn.commit())，做为一个原子操作，但是假设我的业务需求是要把对两个不同数据库的操作做为一个原子操作，你能做的到吗？这时候只能用JTA了。假设操作过程是先往A数据库插一条记录，然后删除B数据库另一个记录，我们自己写代码是控制不了把整个操作做为一个原子操作的。用JTA的话，由App Server来完成控制。

在学习EJB之前要学习对象序列化和RMI，RMI是EJB的基础。接着学习JMS和EJB，对于EJB来说，最关键是要理解EJB是如何通过RMI来实现对远端对象的调用的，以及在什么情况下要用到EJB。

在学习完EJB，JMS这些东西之后，你可能会意识到要急不可待学习两个领域的知识，一个是UML，另一个是Design Pattern。Java企业软件的设计非常重视框架(Framework)的设计，一个好的软件框架是软件开发成功的必要条件。在这个时候，应该开始把学习的重点放在设计模式和框架的学习上，通过学习和实际的编程经验来掌握EJB的设计模式和J2EE的核心模式。

J2EE规范里面，除了EJB，JMS，JTA，Servlet/JSP，JDBC之外还有很多很多的企业技术，这里不一一进行介绍了。

另外还有一个最新领域Web Services。Web Services也完全没有任何新东西，它像是一种黏合剂，可以把不同的服务统一起来提供一个统一的调用接口，作为使用者来说，我只要获得服务提供者给我的WSDL（对服务的描述），就够了，我完全不知道服务器提供者提供的服务究竟是EJB组件，还是.Net组件，还是什么CORBA组件，还是其他的什么实现，我也不需要知道。

Web Services最伟大的地方就在于通过统一的服务提供方式和调用方式，实现了整个Internet服务的共享，是一个非常令人激动的技术领域。Web Services好像目前还没有什么很好的书籍，但是可以通过在网络上面查资料的方式来学习。

方法篇

Java作为一门编程语言，最好的学习方法就是写代码。当你学习一个类以后，你就可以自己写个简单的例子程序来运行一下，看看有什么结果，然后再多调用几个类的方法，看看运行结果，这样非常直观的把类给学会了，而且记忆非常深刻。

然后不应该满足把代码调通，你应该想想看如果我不这样写，换个方式，再试试行不行。记得哪个高人说过学习编程就是个破坏的过程，把书上的例子，自己学习Documentation编写的例子在运行通过以后，不断的尝试着用不同的方法实现，不断的尝试破坏代码的结构，看看它会有什么结果。通过这样的方式，你会很彻底的很精通的掌握Java。

举个例子，我们都编过Hello World


public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}




很多初学者不是很理解为什么main方法一定要这样来定义public static void main(String[] args)，能不能不这样写？包括我刚学习Java的时候也有这样的疑问。想知道答案吗？很简单，你把main改个名字运行一下，看看报什么错误，然后根据出错信息进行分析；把main的public取掉，在试试看，报什么错误；static去掉还能不能运行；不知道main方法是否一定要传一个String[]数组的，把String[]改掉，改成int[]，或者String试试看；不知道是否必须写args参数名称的，也可以把args改成别的名字，看看运行结果如何。



我当初学习Java的时候就是这样做的，把Hello World程序反复改了七八次，不断运行，分析运行结果，最后就彻底明白为什么了main方法是这样定义的了。



此外，我对于staic，public，private，Exception，try{ }catch {}finally{}等等等等一开始都不是很懂，都是把参考书上面的例子运行成功，然后就开始破坏它，不断的根据自己心里面的疑问来重新改写程序，看看能不能运行，运行出来是个什么样子，是否可以得到预期的结果。这样虽然比较费时间，不过一个例子程序这样反复破坏几次之后。我就对这个相关的知识彻底学通了。有时候甚至故意写一些错误的代码来运行，看看能否得到预期的运行错误。这样对于编程的掌握是及其深刻的。



其中特别值得一提的是JDK有一个非常棒的调试功能，-verbose


java –verbose
javac –verbose 以及其它很多JDK工具都有这个选项
-verbose




可以显示在命令执行的过程中，JVM都依次加载哪里Class，通过这些宝贵的调试信息，可以帮助我们分析出JVM在执行的过程中都干了些什么。

另外，自己在学习过程中，写的很多的这种破坏例程，应该有意识的分门别类的保存下来，在工作中积累的典型例程也应该定期整理，日积月累，自己就有了一个代码库了。遇到类似的问题，到代码库里面 Copy & Paste ，Search & Replace，就好了，极大提高了开发速度。最理想的情况是把一些通用的例程自己再抽象一层，形成一个通用的类库，封装好。那么可复用性就更强了。



所以我觉得其实不是特别需要例程的，自己写的破坏例程就是最好的例子，如果你实在对自己写的代码不放心的话，我强烈推荐你看看JDK基础类库的Java源代码。在JDK安装目录下面会有一个src.zip，解开来就可以完整的看到整个JDK基础类库，也就是rt.jar的Java源代码，你可以参考一下Sun是怎么写Java程序的，规范是什么样子的。我自己在学习Java的类库的时候，当有些地方理解的不是很清楚的时候，或者想更加清晰的理解运作的细节的时候，往往会打开相应的类的源代码，通过看源代码，所有的问题都会一扫而空。

一、引言　我为什么要写这篇文章　

　　首先，我要限定我文章的范围，我讨论的问题局限于桌面应用开发领域和企业应用开发领域，所以我的结论并不适用于整个软件开发界，比如我说C语言已经退出历史舞台，这对于写嵌入式系统的人和编写操作系统内核的人
来说显然是错了。我写这篇文章的目的主要是：

　　　*简单的介绍并评价当前主流技术

　　　*比较当前的主流技术

　　　*预计技术的演变

　　如果你想做程序员或者已经是个程序员，你可能会面对这些困惑：

　　　*学什么语言呢？Delphi、C++、VB、Java、C#、PHP、Python?

　　　*选择什么开发工具呢？Delphi、VC、C++Builder、JBuilder?

　　当你已经入了门，有了一定的基础之后（可能已经通晓了几种语言），你会面临进一步的困惑：

　　　*MFC和VCL之间是什么关系？

　　　*J2EE到底是什么？.Net到底是什么？两者有什么本质的区别，我应该学习哪一个呢？

　　　*COM那么复杂，为什么很多地方都用到它？我必须学习它吗？

　　如果是作为一个软件公司，如果不是那么大，如果你的公司还没有一个真正的技术上的灵魂人物，那么你也会面临同样的困惑。技术问题纷繁复杂，让你不知所从，而且真正的精通每一项技术都需要巨大的时间和人力的投入
，你怎么办？选择哪种技术作为公司的主流技术呢？选择的方向是否正确是个关乎你的公司的生死存亡的问题。你面临着这些困惑吗？如果是，那么请让我试着为你拨云见日。
　　我的故事

　　在我上大学之前，我从没见过计算机。大学的时候，正是Dos和FoxBASE的年代，也正是计算机软件开发世界几件伟大的事情发上的时候：(Windows　3.1、Borland　C++3.1、Visua
l　Basic1.0的推出也是伟大的事情，但那时候我还不知道计算机为何物)Widnows　95推出，并开始应用；Visual　Basic5.0推出，开发工具中第一次出现了成熟的、被广泛应用的Auto　
Code　Completion技术；Java推出；ASP技术开始盛行,Windows　DNA技术被理解和接受；标准C++诞生;Visual　C++6.0推出；J2EE规范推出。

　　成为一个程序员对我而言并不顺利，因为我不是科班出身。我入门的程序语言是FoxBASE，这让我一直对FoxBASE有种特殊的感情，我也正是通过VisualFoxPro3.0转写Windows程序的，
如果没有它，我也许就不会成为一个程序员了。后来，在大学期间接触到了InterDEV，那是个写ASP程序的开发工具，还有Java，也是那时候接触的，当时有点盲目崇拜的意思（我想我喜欢Java的一个原因可
能是刚开始学C的时候很受挫折）。毕业之后，我就是凭借着自己写的一个ASP网站找到了自己的第一份工作——说来惭愧，我从来也没有成为一个C程序员。

　　我真正的熟悉Java是在我翻译了一本Java数据结构的书和写了一套完整的GIS系统之后（说起此事，我要感谢一下我的公司，但因为这些故事与本文的主题无关，所以这里就不多说了）。再后来，我自己学习了标
准C++和COM技术。有点像履历表了是吗？提到这些，我只是希望作为读者的你能够了解一下我的知识体系，从而能够知道我大概要讲些什么；同时也希望你能够原谅我可能犯的错误——我在这里说的话，并不一定就是最后
的结论，虽然“共同探讨”这个词几乎是粗制滥造的书的作者专用语了，但我在这里引用它是真诚的，我愿意看到你的反馈。要涉及的话题在开始文章的正题之前，我先大概地介绍这篇文章将会涉及到哪些知识。如果你是初学者
，希望你不要被吓倒，这虽然是一篇技术文章，但我不会过多的讨论技术细节，如果你不懂我说的这些东西，也没关系，我本来就希望通过我的文章帮助你做出一个选择，不再走很多人已经走过的弯路，你这要记住结论就可以了
，随着你知识的增长，以后你会渐渐明白；如果你已经通晓了这些技术或其中的大部分，那么我相信读了这篇文章你会有一些另外的收获。

　　主流的程序设计语言：C++、Delphi(ObjectPascal)、Java、C#

　　桌面应用程序框架：MFC、VCL、QT、JavaAWT\SWING、.Net

　　企业应用程序框架：WindowsDNA（ASP、COM、COM+）、J2EE、.NetFramework

　　开发工具：VisualBasic、Delphi、VisualC++、C++Builder、VisualC#
二、正文

　　现在让我们开始我的正文吧。首先，我来完成这篇文章的第一个目标：介绍并评价当前主流技术。我指的今天的主流技术是：

　　　*程序设计语言：C++\Delphi（本来应该是ObjectPascal，但为了简单，我就语言和工具混为一谈吧）\Java\C#(虽然他刚刚推出，但因为微软为之倾注了大量心血，一定会成为一种重要
的开发语言)

　　　*桌面应用程序框架:MFC\VCL

　　　*企业应用程序框架:WindowsDNA\J2EE\.Net

　　　*COM技术：我单独提出这项技术，是因为它无法简单的被视为语言、桌面应用程序框架或企业应用程序框架，它与这些都有关系。

　　2.1　程序设计语言

　　2.1.1　C++语言的演进

　　最初要从二进制代码和汇编说起，但那太遥远了。我们就从面向过程的语言说起吧（包括Basic\C\Fortran\Pascal）。这种面向过程的高级语言终于把计算机带入了寻常的应用领域。其中的C语言因
为它的简单和灵活造就了Unix和Windows这样的伟大的软件。

　　面向对象的语言是计算机语言的一个合乎逻辑的进化，因为在没有过多的影响效率、简单性的前提下提供了一种更好的组织数据的方法，可使程序更容易理解，更容易管理——这一点可能会引出不同意见，但事实胜于雄辩，
C++终于让C语言的领地越来越小，当今还活着的计算机语言或多或少的都具备面向对象的特征，所以这一点并不会引起太多困惑。C++的成功很大程度要归因于C，C++成为它今天的样子是合乎逻辑的产物。因为在面向
过程的时代，C几乎已经统一天下了。今天著名的语言象Java\C#都从C借鉴了很多东西，C#本来的意思就是C++++。其实C++曾经很有理由统一面向对象程序设计语言的天下来着，但可惜的是，C++太复杂了
。即使是一个熟练的程序员，要你很清楚的解释一些问题你也会很头痛。举几个还不是那么复杂的例子来说：

　　对=的重载\成员转换函数\拷贝构造函数\转化构造函数之间有什么区别和联系呢？

　　定义一个类成员函数private:virtualvoidMemFun()=0;是什么意义呢？

　　int(*(*x(int))[4])(double);是什么意思？

　　还有其他的特征，比如说可以用来制造一种新语言的typedef和宏（虽然宏不是C++的一部分，但它与C++的关系实在太密切了），让你一不小心就摔跤的内存问题（只要new和delete就可以了吗？有没
有考虑一个对象存放在容器中的情况？）……诸如此类，C++是如此的复杂以至于要学会它就需要很长的时间，而且你会发现即使你用C++已经好几年了，你还会发现经常有新东西可学。你想解决一个应用领域的问题——比
如说从数据库里面查询数据、更改数据那样的问题，可是你却需要首先为C++头痛一阵子才可以，是的，你精通C++，你可以很容易的回答我的问题，可是你有没有想过你付出了多大的代价呢？我不是想过分的谴责C++，
我本人喜欢C++，我甚至建议一个认真的开发普通的应用系统的程序员也去学习一下C++，C++中的一些特性，比如说指针运算\模板\STL几乎让人爱不释手，宏可以用几个字符代替很多代码，对系统级的程序员来说
，C++的地位是不可替代的，Java的虚拟机就是C++写的。C++还将继续存在而且有旺盛的生命力。
　　2.1.2　Java和C#

　　Java和C#相对于C++的不同最大的有两点：第一点是他们运行在一个虚拟环境之中，第二点是语法简单。对于开发人员而言，在语法和语言机制的角度可以把Java和C#视为同一种语言。C#更多的是个政治的
产物而不是技术产物。如果不是Sun为难微软的话，我想微软不会费尽心力推出一个和Java差不多的C++++，记得Visual　J++吗，记得WFC吗？看看那些东西就会知道微软为Java曾经倾注了多少心血
。而且从更广泛的角度来说，两者也是非常相似的——C#和Java面对的是同样的问题，面向应用领域的问题：事务处理、远程访问、Webservice、Web页面发布、图形界面。那么在这一段中，我暂且用Jav
a这个名字指代Java和C#两种语言——尽管两者在细节上确实有区别。Java是适合解决应用领域的问题的语言。最大的原因Java对于使用者来说非常简单。想想你学会并且能够使用Java需要多长时间，学会并
且能够使用C++要多长时间。由于Java很大程度上屏蔽了内存管理问题，而且没有那么多为了微小的性能提升定义的特殊的内容（比如说，在Java里面没有virtual这个关键字,Java也不允许你直接在栈上
创建对象，Java明确的区分bool和整型变量），他让你尽量一致的方式操作所有的东西，除了基本数据类型，所有的东西都是对象，你必须通过引用来操作他们；除了这些之外，Java还提供了丰富的类库帮助你解决
应用问题——因为它是面向应用的语言，它为你提供了多线程标准、JDBC标准、GUI标准，而这些标准在C++中是不存在的，因为C++并不是直接面向解决应用问题的用户，有人试图在C++中加入这些内容，但并不
成功，因为C++本身太复杂了，用这种复杂的语言来实现这种复杂的应用程序框架本身就是一件艰难的事情，稍后我们会提到这种尝试——COM技术。渐渐的，人们不会再用C++开发应用领域的软件，象MFC\QT\C
OM这一类的东西最终也将退出历史舞台。
2.1.3　Delphi

　　Delphi是从用C++开发应用系统转向用Java开发应用系统的一个中间产物。它比C++简单，简单的几乎象Java一样，因为它的简单，定义和使用丰富的类库成为可能，而且Delphi也这么做了，结果
就是VCL和其他的组件库。而另一方面，它又比运行于虚拟环境的Java效率要高一些，这样在简单性和效率的平衡之中，Delphi找到了自己的生存空间。而且预计在未来的一段时间之内，这个生存空间将仍然是存在
的。可以明显的看出，微软放弃了这个领域，他专注于两方面：系统语言C++和未来的Java(其实是.Net)。也许这对于Borland来说，是一件很幸运的事情。如果我能够给Borland提一些建议的话，那
就是不要把Delphi弄得越来越复杂，如果那样，就是把自己的用户赶到了C++或Java的领地。在虚拟机没有最终占领所有的应用程序开发领域之前，Delphi和Delphi的用户仍然会生存得很好。

　　2.2桌面应用程序框架

　　目前真正成功的桌面应用程序框架只有两个，一个是MFC，一个是VCL，还有一些其他的，但事实上并未进入应用领域。遗憾的是我对两个桌面应用程序框架都不精通。但这不妨碍我对他做出正确的评价。

　　2.2.1MFC

　　MFC（还有曾经的OWL）是SDK编程的正常演化的结果，就象是C++是C的演化结果一样。MFC本身是一件了不起但不那么成功的作品，而且它过时了。这就是我的结论。MFC凝聚了很多天才的智慧——当然，
OWL和VCL也一样，侯捷的《深入浅出MFC》把这些智慧摆在了我们的面前。但是这件东西用起来估计不会有人觉得很舒服，如果你一直在用Java、VB或者Delphi，再回过头来用MFC，不舒服的感觉会更加
强烈。我不能够解释MFC为什么没有能够最终发展成和VCL一样简单好用的桌面程序框架，也许是微软没精力或者没动力，总之MFC就是那个样子了，而且也不会再有发展，它已经被抛弃了。我有时候想，也许基于C++
这种复杂的语言开发MFC这样的东西本身就是错误的——可以开发这样的一个框架，但不应当要求使用它的人熟悉了整个框架之后才能够使用这个系统，但很显然，如果你不了解MFC的内部机制，是不太可能把它用好的，我
不能解释清楚为什么会出现这种现象。

　　2.2.2VCL

　　相比之下VCL要成功的得多。我相信很多使用VCL的人可能没有像MFC的用户研究MFC那样费劲的研究过VCL的内部机制。但这不妨碍他们开发出好用好看的应用程序，这就足够了，还有什么好说的呢？VCL给
你提供了一种简单一致的机制，让你可以写出复杂的应用程序。在李维的Borland故事那篇文章中曾经说过，在Borland　C++　3.1推出之后Borland就有人提出开发类似C++　Builder一类
的软件，后来竟未成行。是啊，如果C++　Builder是在那个时候出现的，今天的软件开发领域将会是怎么样的世界呢？真的不能想象。也许再过一段时间，这些都将不再重要。因为新生的语言如Java和C#都提供
了类似于VCL的桌面应用程序框架。那个时候，加上Java和C#本身的简单性，如果他们的速度有足够块，连Delphi这种语言也要消失了，还有什么好争论的呢？只是对于今天的桌面程序开发人员来说，VCL确实
是最好的选择。
　　2.3　企业应用程序框架

　　2.3.1　Windows　DNA

　　Windows　DNA的起源无从探究了。随着.Net的推出，事实上Windows　DNA将成为历史的陈迹。Windows　DNA虽然是几乎所有的企业应用程序开发人员都知道的一个名词，但我相信Win
dows　DNA事实上应用的最广泛的是ASP而不是COM+。真正的COM开发有多少人真正的掌握了呢，更不要提COM+(我有必要解释一下：COM+是COM的执行环境，它提供了一系列如事务处理、安全等基础
服务，让应用程序开发人员尽量少在基础架构设计上花精力)——当然我这里指的COM开发不是指VB下的COM开发，所以要这么说，是因为我觉得如果不能理解用C++进行COM开发，也就不能真正的理解COM技术。
如果以一种技术没有被广泛理解和应用作为失败的标志，那么Windows　DNA实际上是失败了，但这不是它本身的错，而是基于C++的COM技术的失败造成的。多层应用、系统开发角色分离的概念依然没有过时。

　　2.3.2　J2EE

　　J2EE是第一套成功的企业应用程序开发框架。因为它把事务处理、远程访问、安全这些概念带入了寻常百姓家。这种成功我认为要归因于Java的简单性。Java的简单，对于J2EE容器供应商来说一样重要。开
发一个基于Java的应用服务器要比基于C++的更容易。而且由于Java的简单性，应用系统开发者出错的机会也会少一些，不会像C++的开发者那样受到那么多挫折。开发基于Java的企业应用系统的周期会更短，
这恐怕是不容争辩的事实。不论如何，是J2EE让事务处理、远程访问、安全这些原来几乎都是用在金融系统中的概念也被一般的企业用户使用并从中获得利益。

2.3.3　.NET

　　.Net有什么好说的呢？其实，它不过是微软的J2EE。事务处理、安全、远程访问，这些概念在.Net中都找得到。更有力的说明是，微软也利用了.Net实现了一个PetStore。所以，.Net与J2E
E几乎是可以完全对等的。但微软确实是一家值得尊敬的公司——我指从技术上，象Web　form这种东西，我相信很多Web应用开发者都梦想过甚至自己实现过，但Sun却一直无动于衷，而且似乎Borland也没
有为此作过太多努力，好像有过类似的东西，但肯定是不怎么成功——Borland已经很让人敬佩了，我们也许无法要求太多。
　　2.4　COM技术

　　COM应当是个更广泛的词汇，其实我觉得Axtive　X、OLE、Auto　mation、COM+都应当提及，因为如果你不理解COM，上面的东西你是无法理解的。而且，我只是想说明COM是一种即将消亡
的技术，仅仅说说COM的复杂性和他的问题就够了，所以不会提及那些东西。为什么会出现COM技术？COM的根本目标是实现代码的对象化的二进制重用，进而实现软件的组件化、软件开发工作的分工。这要求他做到两点
：第一，能够跨越不同的语言，第二，要跨越同一种语言的不同编译器。COM技术为这个目标付出了沉重的代价，尤其是为了跨越不同的编译器，以至于无论对于使用者而言还是开发者而言，他都是一个痛苦的技术。但幸运的
事，这一切终归要结束了。

　　让我们从这个目的出发看看COM为什么会成为它现在的样子。其实COM不是什么新玩意，最初的DLL就是重用二进制代码的技术。DLL在C的年代可能还不错，但到了C++的年代就不行了。原因在于如果你在.h
文件中改变了类定义（增加或者减少了成员变量），代码库用户的代码必须重新编译才可以，否则用户的代码会按你的旧类的结构为你的新类分配内存，这将产生什么后果可想而知。这就是为什么通过接口继承和通过接口操作对
象成为COM的强制规范的原因，能够通过对象的方式组织代码是COM的重要努力。那么著名的IUnknown接口又是怎么回事呢？这是为了让使用不同编译器的C++开发人员能够共享劳动成果。

　　首先看QueryInterface，因为COM是基于接口的，那么一个类可能实现了几个接口，而对于用户来说，你又只能通过操作接口来操作类，这样你必须把类造型成某个特定的接口，使用Dynamic_ca
st吗？不行，因为这是编译器相关的，那么，就只好把它放在类的实现代码中了，这就是QueryInterface的由来。至于AddRef和Release，他们产生的第一个原因是delete这个操作要求一个
类具有虚析构函数（否则的话，他的父类的析构函数将不会被调用），但不幸的是不同的编译器中析构函数在vtbl中的位置并不相同，这就是说你不能让用户直接调用delete，那么你的COM对象必须提供自己删除自
己的方法；另外的原因在于一个COM对象可能作为几个接口在被用户同时使用，如果用户粗暴的删掉了某个接口，那么其他的接口也就不能用了，这样，只好要求用户在想用一个接口的时候通过AddRef通知COM对象“
我要使用你了，你多了一个用户”，而在不用之后要调用Release告诉COM对象“我不用你了，你少了一个用户”，如果COM对象发现自己没有用户了，它就把自己删掉。

　　再看看诡异的HRESULT，这是跨语言和跨编译器的代价。其实，异常处理是物竞天择的结果——连一直用效率作标榜的C++都肯牺牲效率来实现这个try-catch，可见它的意义，但COM为了照顾那些低级
的语言居然抛弃了这个特征——产生的结果就是HRESULT。我们可以看看他是多么愚蠢的东西。首先，我们要通过一个整数来传递错误信息，通过IErrorInfo来查找真正的错误描述，本来在现代语言中一个tr
y-catch可以解决的问题，现在我们却需要让用户和开发者都走很多路才能解决，你怎么评价这个结果？其次，由于这个返回计算结果的位置被占用了，我们不得不用怪异的out参数来返回结果。想想一个简单的int
　add(intop1,intop2)在COM中竟然要变成HRESULT　add(intop1,intop2,int*　result)，我不知道你对此作何感想。而且由于COM的方法无法返回一个对象而只
能返回一个指针，为了完成一个简单的std::string　GetName()这一类的操作，你要费多少周折——你需要先分配一块内存空间，然后在COM实现中把一个字符串拷贝到这个空间，用完了你要删掉这个空
间，不知道你是否觉得这种工作很幸福，反正我觉得很痛苦。还有COM为了照顾那些解释性的语言，又加入了Automation技术，你有没有为此觉得痛苦？本来一个简单的方法调用，现在却需要传给你一个标志变量，
然后让你根据这个标志变量去执行相应的操作。（这一点我现在仍然不明白，为什么解释性的语言需要通过这个方式来执行一个方法）。“我受够了，我觉得头痛”，你会说，是啊，我想所有的人都受够了，所有这些因素实际上
是把COM技术变成了一头让人无法驾驭的怪兽。

　　人对复杂事物的掌控能力终究是有限的，C++本身已经够复杂了，COM的复杂性已经超出了我们大部分人的控制能力，你需要忍受种种痛苦得到的东西与你付出的代价相比是不是太不值得了？我们学习是为了解决问题，
而现在我们却需要为了学习这件事情本身耗费太多的精力。这些痛苦的东西太多了，我在这里说到的，其实只是一小部分而已。计算机技术是为人类服务的，而不是少数人的游戏（我想COM技术可能是他的设计者和一部分技术
作者的游戏），难道我们愿意成为计算机的奴隶吗？通过一种过于复杂的技术抛弃所有的人其实等于被所有的人抛弃，这么多年中选择J2EE的人我相信不乏高手，你是不是因为COM的过于复杂才选择J2EE的？因为它可
以用简单的途径实现差不多的目标——软件的“二进制”重用、组件化、专业分工（容器开发商和应用开发商的分工）。事实上，你是被微软所抛弃的，同时，你也抛弃了微软。

　　现在让我们回来吧，我把你带进了COM的迷宫，现在让我把你领回来。再让我们看看COM到底想实现什么目标，其实很简单，不过是代码的二进制重用，也就是说你不必给别人源代码，而且你的组件可以象计算机硬件那
样“即插即用”。我们回过头来看看Java，其实，这种二进制重用的困难是C++所带来的（这不是C++本身的错，而是静态编译的错），当Java出现的时候，很多问题已经不存在了。你不需要一个头文件，因为Ja
va的字节码是自解释的，它说明了自己是什么样子的，可以做什么事情。不像C++那样需要一个头文件来解释这些事情；也不需要事先了解对象的内存结构，因为内存是在运行的时候才分配的。如果我们现在再回过头来解决
COM要解决的问题，你会怎么做呢？首先你会不再选择C++这种语言来实现代码的“二进制”重用，其次，你会把所有的语言编译成同样的“二进制”代码（实际上，应当说是字节码），这显然是更聪明的做法，从前COM
试图在源代码的级别抹平二进制层次的差异，这实际上是让人在做本来应当由机器做的事情，很愚蠢是吗？但他们一直做了那么多年，而且把这个痛苦带给了整个计算机世界——因为他们掌握着事实的标准，为了用户，为了利润
，为了能够在Windows上运行，尽管你知道你在做着一个很不聪明的事情，但你还是做了。

　　COM技术为了照顾VB这个小兄弟和实现统一二进制世界的野心，实在浪费了太多的精力。首先，落后的东西的消亡是必然的，就象C、Pascal在应用领域的消亡一样，Basic一点一点的改良运动是不符合历史
潮流的做法，先进的东西和落后的东西在一起，要么先进的东西被落后的东西拖住后腿，要么是同化落后的东西，显然我们更愿意看见后者，现在Basic终于被现代的计算机语言同化了。其次，统一二进制世界好像不是那么
简单的事情，而且也没什么必要，微软的COM技术奋战了10年，现在也只有他自己和Borland支持，.Net终于放弃了这个野心。这一切终于要结束了。

　　过去J2EE高歌猛进地占领着应用开发的领地，COM在这种进攻面前多少显得苍白无力。现在微软终于也有了可以和J2EE一较长短的.NET，对于开发人员来讲，基于字节码的组件的二进制重用现在是天经地义的
事情；你不用再为了能够以类方式发布组件做那么多乱七八糟的事情，因为现在所有的东西本来就是类了；实现软件开发的分工也很自然，你是专业人员，就用C#吧，你是应用开发人员，你喜欢用VB.Net，你就用吧，反
正你们写的东西最终都被翻译成了一样的语言（其实我觉得这一点意义不大，因为一些不那么好用的语言被淘汰是正常的事情，C风格成为程序设计语言的主流风格，肯定是有它的原因的，语言的统一其实是大势所趋，就象中国
人民都要说普通话一样，我觉得Java不支持多语言算不上缺点——本来就是一种很好看很好用的语言了，为什么要把简单问题复杂化呢？）。COM不会在短期内死去，因为我估计微软还不会马上用C#开发Office和
Windows的图形界面部分，但我相信COM技术退出历史舞台的日子已经不远了，作为一般的开发人员，忘了这段不愉快的历史吧——你将不会在你的世界里直接和COM打交道。若干年以后，我想COM也许会成为一场
笑话，用来讽刺那种野心过大、钻牛角尖的愚蠢的聪明人。

结论

　　说了很多，应该是有个结论的时候了。我似乎做了一件冒天下之大不韪的事情，因为我评价了主流技术，还要试图进行比较，好像某个名人说过：“C++　Builder也好，Visual　C++也好，能在市场上立
足，肯定都是有自己的过人之处的，而且一个人精通数种开发语言、数种开发工具是不可能的事情”，言下之意就是说你不要对这些东西妄加评论，但怎么可以不评论？好像高手都不屑于说哪种语言好、哪种语言坏，我不知道什
么时候形成了这种风气。简单地说C++比Java好或者Java比C++好显然是愚蠢的行为，但如果让你用Java写驱动程序，用C++开发一个MIS系统是不是愚蠢的行为呢？显然更愚蠢。我想，作为一个独立的能
思考的人，外界的东西对你而言总是有好有坏，而且你的生命有限，你还要享受你的生活，所以你必须做出选择。所以，起码评价这些东西对我自己而言是正确的——只要我有能力评价，那我就说出我的评价吧。

　　对于计算机语言来说，未来真正重要的语言只有三种C++、Java和C#。C++将更适合于专业的计算机公司编写图形界面系统（比如KDE）、虚拟机（比如Java虚拟机或者.Net运行环境）、杀毒软件或者
其他的盒装软件（比如说Photoshop、Dreamweaver）这一类的东西。而且C++适合程序员做学习之用，能对C++有一定理解的程序员往往也应该能更深刻的理解Java、C#，这有助于编写更好的软
件。如果是开发为客户定制的应用系统Java、C#是更好的选择。包括桌面应用和Web应用。

　　至于其他的语言比如VB.Net其实并没有太大的意义。Delphi在未来一段时间将继续存在，而且活得不错。最重要的原因在于，第一它有一套丰富的组件库，第二它效率相对算高的，第三它简单。如果虚拟机的执
行效率赶不上Delphi，它就有存在的理由，但从过去的Visual　J++来看，微软的虚拟机做得确实可以很好，加上.Net的组件库和C#的简单性并不差，所以从长远来看Delphi可能不那么乐观。

　　其实上面的比较也包含了桌面应用程序框架的比较。在现在来说VCL无疑最好的，MFC已经退出历史舞台。.Net中所带的桌面应用程序框架将最终统一桌面应用领域（但不包括微软和Borland这样的专业公司
，因为他们要作出最好用而且效率最高的软件）。至于Java中所带的桌面应用程序框架，实在让人哭笑不得。这个结论的变数是.Net运行环境的执行效率。如果.Net中的虚拟机象Java的一样，那微软就倒霉了，
它等于放弃了桌面应用开发工具领域，但根据微软在Visual　J++上的成就和他推广.Net的背水一战的驾式，.Net在桌面领域失败的可能性不大（但不是没有，起码基于COM的技术在企业应用领域几乎可以说
是全军覆没）。

　　在企业应用程序框架领域，最终只有J2EE和.Net可以决一雌雄。我没有提到CORBA，它也可以算是企业应用程序框架，但他的声势和J2EE或者.NET实在不能同日而语，而且最重要的是只有Borlan
d一家大公司支持它（SUN、IBM、BEA、Borland支持J2EE，微软就不用说了），所以就不详细说他了。那么最终谁会赢呢？我想微软赢的可能性大一些。这样说可能让很多人不快，而且IBM的厉害也是有
目共睹的。但这并不是纯技术问题，就象Windows　NT蚕食Unix的领土那样，那时候微软也是孤军作战。J2EE的问题在于第一：混乱，第二，价高。我相信很多人都对这两点有过不快的经历。你知道写给Web
logic的应用程序不是很顺利地就可以移植到Websphere上的，反过来也一样。但.Net就不一样了，那是微软一个人的作品，根本不存在移植的问题。

　　如果J2EE阵营不想败在这一点上，有三个办法，第一种就是通过制定统一的标准彻底消灭移植问题，第二种是开发一种好用的部署工具（不能象JBuilder那么大、那么慢：），屏蔽不同的应用程序容器之间的区
别，第三种，也是最不可能的，就是J2EE阵营有人能够一统天下。显然，这三种解决办法都不太现实。第二点价高，这是SUN、IBM、BEA、ORACLE传统，也是它们一直让微软的进攻屡屡得手的软肋。我一直不
太能明白他们的西就为什么那么贵。这样想一想：微软的.Net　SDK白送给你，BEA的Web　logic一个CPU的License两万，如果你两种技术都会，如果你给客户的系统报价一样，你选哪种开发技术？
这一点实在让人觉得无可奈何。J2EE有的东西，.Net也有（除了不能跨平台），技术上的细微差别在巨大的价格差异面前还有什么意义呢？当然，SUM、IBM这些大公司也不是等闲之辈。就象Windows　NT
没有消灭Unix一样，J2EE应当会像Windows　NT和Unix的共存一样和.Net共存，只是我想.Net恐怕会占上风。

闲话

　　说完了该说的技术问题，说说闲话吧。有的话放在心里觉得不说出来不舒服，且让我一吐为快:)

　　给入门程序员的建议

　　不知道我在学计算机的时候是不是走了弯路。但我想如果让我重新开始学写程序的话，我会采用一些不同的办法。如果你也正在想成为一个程序员，这些也许会对你有帮助。我觉得可能大概要分几个阶段，第一个阶段应该是
找一门简单的语言入门，比如Java或者C#都应该比较合适，选一本简单的带例子的书（最好不要太厚），按部就班的把书学完。这时候可能还有些懵懵懂懂，但没关系，可以开始做个小小的软件了，重要的事你要自己用那
种语言的方式想思考，如果有项目做，当然更好。之后，你会觉得有点感觉了。如果你象我一样不是科班出身的，接下来应当补习一下计算机专业的课程，我觉得最重要的是数据结构——那些东西你可能永远都不会自己做，C+
+中有漂亮的STL，Java中也为你实现了大部分东西，但我觉得真的有必要学习那些内容，这会加强你用计算机语言思考问题的能力。在进一步，如果你的入门语言不是C++，那你可以补习一下C++，尽管你可能永远
都不会用C++开发程序。C++在现在的计算机世界就象是普通话一样，而且它能让你很容易的理解其他语言中难以理解的问题。学完了C++，那你应当就已经不是一个初级程序员了，欢迎你进入计算机软件开发的世界。

　　印度的软件业

　　我记得好像在CSDN上看见过一篇文章，极力的鼓吹印度的软件业。而且我记得他好像说过一句很刻薄的话“我们公司那些B大的和T大的，一个一个特别牛，牛得看不见人……做起界面极尽奇迹淫巧之能事……”，诸如
此类，总之认为程序员只有象印度的高中生那样乖乖的、懂得UML、会看Function　Specification才算是真正的程序员。我当时觉得很不舒服。我想这个人应该不是B或T大的——哦，别误会，我也不
是——但我觉得好像B大的T大的人没象他说的那样。而且我不明白为什么中国的软件业为什么一定要向印度看齐？作为一家公司，你想获取商业利润，学习印度无可厚非，你大可以找一大堆高中生培训成编程蓝领（我没有轻视
高中生的意思，我相信有很多“高中生”在技术领域取得的成就是让我望尘莫及的），但你不应该因此就把有血有肉有个性的程序员扁得一钱不值。说实话，所谓的编程蓝领不过是工厂里面的装配工，如果有一天工厂里面换了自
动化的设备，这些人就全成了废人！而你要知道并不是这些装配工发明了自动化机器。我想这种话用不着多说，子曰“过犹不及”，你可以喜欢变成蓝领，但不要把问题推向极端，把问题推向极端往往就会犯错误。我们中国可以
在某种程度上学习印度，但好像我们更应该学习美国——只是我们现在没那么富裕——可是微软也不是从一开始就是这样一个伟大的帝国的，IBM也一样

　　附录参考书目

　　阅读如下图书有助于理解本文内容。而且这些书都是好书，值得一读。

　　*《标准C++宝典》
　　*《C++编程思想》
　　*《深入浅出MFC2e》
　　*《COM技术内幕》
　　*《COM本质论》
　　*《Java编程思想》
　　*《精通EJB》第二版
　　*《J2EE编程指南》
　　*《Delphi6开发人员指南》
　　*《C#宝典》
　　*《微软.Net战略》
注：以上文字来源于网上文章

　　如果把诺兰•布什纳尔比作“电子游戏业之父”，那约翰•卡马克就是“第一人称射击游戏之父”，在一家名为id Software的小公司里，卡马克和他的同事通过一部又一部血腥暴力的作品创造并不断革新着这一游戏类别。id所获得的无数荣誉应当归属于它的全体员工，而约翰•卡马克无疑是将整个公司凝聚在一起的粘合剂。 

　　坦白地说，卡马克主要是一名技术天才，id公司出品的每一款游戏都是围绕他所编写的引擎制作而成的，卡马克不断把引擎技术推向新的高度。他为游戏业做出的第一个贡献是实现了卷轴游戏背景图像的流畅性，这一技术在1990年的《指挥官基恩》（Commander Keen）中得到了应用，此前电脑平台上的横向卷轴游戏的背景图像都很不稳定，根本无法同当时游戏机平台上的横向卷轴游戏相比。尽管这一技术在今天看来算不上什么，但它足以显示出卡马克高超的编程能力。 

　　卡马克今天的地位主要归功于他在3D方面的成就，尤其是对3D加速技术不遗余力的倡导和传播。《雷神之锤》刚刚问世的时候，3D加速卡在人们眼里还只是一个可笑的空想而已，只有卡马克对3D技术的威力深信不疑，他为《雷神之锤》制作了一个专门在Verite显卡上运行的特别版本，画面看上去非常漂亮，可惜的是Verite显卡未能在市场上站稳脚跟。随后卡马克又采用OpenGL标准为《雷神之锤》制作了一个新的版本，使所有具备3D加速能力的显卡都能以更快的速度、更高的分辨率渲染出更华丽的图像。到了今天，一些显卡生产商在研发新产品之前甚至会先同卡马克商量一下，以确保他们的硬件可以完美地支持id出品的游戏。卡马克所作的这一切决定性地改变了显卡产业未来的发展。 

　　除了3D方面的成就外，约翰•卡马克还为游戏业带来了许多其它的技术革新，例如网络代码中的客户端侦测、多重纹理、便于修改和可扩展的游戏代码、游戏内部的命令行指令……看来所有该做的都已经被卡马特做完了，可谁知道呢，也许这一切只不过是开始而已。 

　　业内人士对约翰•卡马克的评价： 

　　约翰•霍华德（微软公司）：“他缔造了‘死亡竞赛’和‘平移’等许多新单词。《毁灭战士》和《雷神之锤》系列是继《俄罗斯方块》以及一些早期的街机游戏之后真正触及到电子游戏艺术的精髓的作品。” 

　　比尔•罗帕（Blizzard娱乐公司）：“卡马克是一位技术天才，他在自己的工作领域中一直占据着至高无上的位置，没有人可以超越得了他。那些塑造世界、富于创新精神的游戏设计师博得了我们的尊敬，而约翰•卡马克同样凭借其高超的编程技术在游戏史上获得了他应有的地位，正是他的技术令许多设计师的想法得以实现 
 
 

            传奇程序员John Carmack 访谈实录 

            译者：Frank FiringSquad :www.firingsquad.com/features/carmack/ 
                    John Carmack—网络游戏界的先知 
                    传奇程序员John Carmack对游戏看法 
                    GDC 2004: John Carmack谈游戏开发 

              简介 
              Carmack 对于钱的态度 
              专注和灵感 
              顿悟 
              开放源码 
              关于Linux的其他问题 
              Carmack作为学生 
              Quake 和简洁 
              Id公司的下一款游戏 
              关于游戏行业 
              Id不是一个发行商 
              关于Trinity 
              三维象素和曲线 
              对竞争的看法 
              Carmack的研究 
              综合性问题
            简介 

            藏在幕后的人
            John Carmack是一个几乎不需要介绍的人——Id 
            Software的创始人。该公司开创了第一人称射击类游戏，并且独立地改变了PC动作游戏的定义。从Commander 
            Keen到Doom，再到Quake，Carmack/id的游戏吸引了数百万玩家通宵达旦地在计算机屏幕前击退他们的对手。 
            去年12月底，Firingsquad和Gamers.com获得了一个难得的机会，与John 
            Carmack进行一次长时间的、面对面的访谈。我们利用这次机会进一步了解了John作为一个普通人——而不是一个程序员——的一面。我们还向John询问了他和Id未来的发展计划，以及他对于游戏行业的现状及其发展方向的看法。下面问题以粗体字显示，John的回答以普通文字显示。 

            Firingsquad: 你今年多大？ 
            John: 29岁。
            FS: 你是否认为结婚会影响你的编程工作？ 
            John:不。如果这样想我就不会结婚了。 
            FS: 那么你和Anna[Kang]通常是怎样渡过一天的？ 
            John: 
            最近我们一直在搭建一些火箭模型。我接受了一次访问，有人问我在十几岁时的情况，我提到了火箭、炸弹和一些类似的物品。我想这很有趣，我喜欢这样。当然，现在您可以到互联网上说“我想要这个、这个和这个。” 
            他们现在拥有比我以前所用的强大得多的火箭——这些动力强劲的火箭具有每秒2000牛顿的推动力！ 
            FS: 你和Anna会进行一对一的网络对战吗？ 
            John: 
            就在昨天我们还一块玩了Apple这个游戏，Anna与其中的一个玩家开玩笑——她踢了他一脚。我当时正在与其他一些人开会，所以他们玩了一会，而她一直在逗他玩。但是当我开完会时，他们把我逼进这个家伙的房间里，让我坐下。我进行了反击，取得了一次小规模的胜利。正如我所预料的，我听到了她从建筑物的另一侧发出的诅咒声。她仍然认为另外一个家伙在游戏最后魔术般地获得了技能！ 

            FS: 我阅读了你在以前接受的一些访谈的内容，其中你提到了炸弹等物品。你是一个不听话的小孩，对吗？ 
            John: 
            是的，现在回忆起来，十几岁时的我在很多方面就像是一个傲慢自大的小讨厌鬼。这些年来我已经逐渐成熟起来。现在回想当年，我认为当时的我表现并不好。我的意思是，尽管我很聪明——我当时已经开始编写计算机程序，但是我经常分不清是非。 

            FS: 如果你需要给在自己的学校中存在像你这样的孩子的人提点建议，你会说什么？ 
            John: 
            我已经清楚地知道了我想要做什么。我想要编程——我在12岁时就深知这一点。我知道，这是我想要做的，而且我清楚地知道我想要实现的目标。你不能总是说世界亏欠你想要得到的。但是的确有些时候需要为一个孩子提供一些必要的帮助。我的父母从来没有真正地了解我，因而我没有得到我想要的计算机。我为此责怪了我母亲将近十年，但是我们现在都已经淡忘这件事情了。 
 
 
 
            当时我感到非常沮丧，因为我清楚地知道我想要做什么，但是我却无法做到。人们习惯于认为：如果你想要从事计算机工作，你需要进入MIT，再到一家公司工作，成为一名工程师，遵循“公认的发展道路”。但是我从大学辍学了，随后创建了我自己的公司。我的弟弟选择了一条更加符合惯例的道路。他获得了一个学位，成为了一名股票经纪人，而这正是我母亲希望他做到的。他干得不错，但是并不能像我一样拥有很多辆法拉利跑车来让父母感到自豪。 

            我现在可以说，我和我的母亲现在相处得很好。我们可以讨论这些事情和回忆过去，她意识到她在某些方面犯了错误。但是这有什么用？她不会再抚养别的孩子。 

            Carmack 对于钱的态度
            FS: 你现在已经非常富有——这对你有什么影响？ 
            John: 
            我现在拥有的财富足以让我无需再继续工作；我的确不需要再工作了。这种自由的感觉非常好。因为只要你拥有足够的钱来维持你的生活，你就不必听命于任何人，也不需要想法设法赚更多的钱。尽管有很多人已经非常富有，但是他们仍然屈从于拥有更多财富的诱惑。 

            我基本上拥有我所需要的一切。我已经拥有足够的财富来维持我自己和我的家人的正常生活，因此，没有任何人、任何公司可以对我产生严重的影响。 
            FS: 是否存在一些领域，你认为你可以利用你的财富施加影响？ 
            John: 
            我尽量不像这样考虑问题。在推动其他事情方面，我尽量做到不要太主动。我希望直接解决事情的技术方面的问题。当然我可以用钱来解决一些事情，但是我更希望用直接的方式解决问题。 

            这就是为什么我不是一位很好的经理。我是一位工程师，所以我想要直接解决问题。我希望把环境建立一起，以便更好的解决问题，尽管在很多情况下我意识到还需要完成更大规模的项目。但是这并不是只有我才能做到的。 

            我非常擅长这个领域的工作，而且恰好我很喜欢它，因而我并不想转到其他的领域。我的财富足以让我提前退休，但是我喜欢我现在的状态。 
            在这方面我很反感某些公司的做法。一些创始人原先是非常出色的工程师，但是现在成了他们的部门的主管，因而主要从事管理工作，而不是工程项目。同时，他们所管理的大部分员工在处理实际工作方面远远不如他们当初的水平。 

            我希望这样的事情永远不要发生在我身上。我希望永远处于行业前沿，从事实际的开发工作。当然，回到幕后阅读资料、研究理论和获得更加广泛的视角也会带来一些好处，但是如果你不了解开发的具体细节，例如工程项目与真实世界的联系，你就会变成一个只会夸夸其谈的理论家。你可以从理论家的所作所为和一个从事真正的开发工作的工程师的工作之间看到这种巨大的差别。 

            在过去的两个项目中，我的时间被分成了几段。我有大约三个月的时间进行纯粹的理论研究。我目前正处于这个阶段，在这期间我需要与不同的人进行合作。随后我将用大约16个月的时间从事项目的开发工作。更多的关注研究性质的工作对我来说相当重要，但是我并不希望将我的大部分时间用于理论研究。我认为，研究的关键在于找出一种新的方法，但是当您想要真正地采取行动时，仅仅拥有这些理论知识是远远不够的。 

            专注和灵感
            FS: 你对工作的专注让人惊叹。看来你是唯一适合现在这项工作的人。 
            John: 
            专注非常有用。在现在这个环境中，我认为软件是一种几乎最理想的介质。但是如果不做这一行，我可能会成为一名工程师或者某种意义上的科学家。我可以从事任何一种“硬科学”。 

            软件具有很多与众不同的优点。从事物理试验的研究人员需要用一年的时间进行准备和制作工具，然后还要花一年时间来分析试验结果。但是在开发软件时，你可以立即看到运行结果。你只需要坐在那里对程序进行反复的调试。你可以立即运行程序。对于所有智力探索活动来说，这是最容易适应的工作方式。我很庆幸自己生活在这个软件业非常繁荣的时代。 
 
 
 
            我再次想起当我还是一个年轻人时，我没有我想要的计算机。我感到非常沮丧。我觉得我“正在错过一个很好的机会”。我觉得自己应当编写这些游戏，例如早期的Apple 
            II游戏。我之所以感到由衷的沮丧，是因为我觉得自己错过了最佳时机。当然当时我并不知道我可以抓住“下一个”最佳时机。 
            你读过Steven Levy写的《黑客》吗？ 
            FS: 读过，这本书非常棒！ 
            John: 
            我在十几岁的时候读了这本书。在看到第三章时，我感到“天啊，这才是我应该做的！”大约10年以后，我回想起来自己当时的想法：“如果那本书有第四章，也许我会加入那个行业。”这是一个非常有趣的想法。 

            现在看这段经历会觉得很有意思。当我是一个年轻人时我觉得错过了自己的最佳时机。因为当时是PC的早期发展阶段的黄金时期，我为自己没有抓住那次机会深感遗憾。 

            FS: 你是否认为编程工作和将想法转变为程序代码的过程激发了你对编程的兴趣？或者是你在Apple II和PC发展早期所玩的某些游戏？ 
            John: 我可以说出我当时非常喜欢的游戏的名字，但是我真正喜欢的是进行抽象的编程。我喜欢这项工作的很多独特之处。 
            很多人加入游戏行业的原因就是他们喜欢游戏，而且乐于创新。 
            我对编程的热爱则来自于一种更加抽象的感觉。我可以从为Linux编写设备驱动程序中获得很大的乐趣。我还喜欢编写数据库管理程序或者其他程序，因为在开发过程中总是会遇到一些有趣的问题。有些事情可以给我带来更多的满足感。图像和游戏很可能是编程工作中最能给人带来成就感的领域。 

            FS: 为什么呢? 
            John: 
            因为你可以得到非常形象的反馈信息。当你编写一个图像算法时，它可以为你绘制一副图片。尽管数据编程会通过其他的方式给人以满足感，但是人类显然对可视的对象和必须通过符号理解的事物更感兴趣。这是图像编程极具吸引力的基本原因。但是我们必须进行很多方面的研究。我喜欢这项工作的所有领域，但是游戏开发总是会让你在克服一些极具挑战性的问题之后才能领会到它给你带来的满足感。 

            我在早期很喜欢RPG游戏，例如Ultimas，Wizardrys和所有类似的游戏。我为Apple 
            II开发的一些非常早期的游戏基本上就是Ultima的翻版。我还喜欢所有的经典决斗游戏。 
            顿悟
            FS: 
            从某种意义上说，你是否认为“龙与地下城”是你所希望看到的、带有一定的文字和对话的游戏模式？它是否像Quake引擎一样，是一种可以在其中添加各种内容的游戏结构？ 

            John: 它就像是能够从头开始开发新的游戏，使用一种对你没有任何限制的方法。 
            事实上，我们最初打算将Quake开发为一个RPG游戏——并不是一个完全意义上的RPG游戏，而是一个奇幻游戏。但是因为Quake的复杂的开发流程，它后来的发展完全偏离了这个轨道。我一直非常愿意说明我们在刚开始时对我们所开发的游戏制定的目标。尽管它们成为了与我们的目标截然不同的游戏，但是我很满意最终的结果。我们不大可能在开发一款奇幻/角色扮演游戏。 

            FS: 我听说你减少了你对“龙与地下城”的管理工作。 
            John: 
            从Wolfenstein开始，整个公司都在每个周末玩我们所开发的游戏。玩游戏的时间在我们开发Doom阶段有所减少。我们去年纯粹为娱乐开发了几款游戏。但是它花了我们不少时间。要完成出色的工作，你必须用一天时间玩游戏，再用一天时间准备，但是我现在不可能再为其他的工作牺牲20%的时间。 

            FS: 你有一种特别的专注和灵感——你可以怎样改进一个算法或者技术。你多久会遇到一次这样的顿悟？ 
 
             John: 
            我认为很多人都过于强调顿悟的重要性。顿悟的确很重要，但是只有在你清楚地了解一项工作的来龙去脉之后获得顿悟。事实上，很多出色的工作并不是顿悟的结果，而是辛勤工作的结果。很多人都误以为顿悟是最重要的。有时候它的确是，但是在95%的情况下它仅仅是你对你所掌握的知识的冷静分析的结果。 

            让工作成功的关键并不是一个天才的决策，而是500个明智的选择。更加重要的是始终做出明智的决策。制定一个天才的决策和很多平庸的决策还不如在整个过程中始终制定比较明智的决策。你必须要做出很多正确的决定。 

            即使在开发完Quake 
            3之后，我的任务清单上仍然有数千个有待进一步改进的细节。因此，关键在于了解所有必须完成的工作，进而找出“最有效的击球点”。例如“这些工作可以完成大量的任务，但是会带来一定的副作用。”或者“完成这项工作可能需要几天时间，但是它会让其他一些环节变得不太稳定，因此我不会去做这项工作。” 

            我当然希望遇到顿悟——当时我可能正在做某项工作，忽然间意识到可以采用一种更好的方法。这的确非常有用，但是我不能指望这种情况每天都会发生。实际上比较常见的情况是，当我回到家里时我可以告诉Anna：“今天我想出了一个新主意！”这种情况相当常见，而且非常有用。 

            开放源码 
            FS: 很多人都认为你是全世界最出色的游戏工程师之一。你认为在今后几年中，这个世界上是否还有足够的任务和深度来让你保持足够的兴趣？ 
            John: 
            当然，还有很多难题需要解决。目前，我正在利用我的很多闲暇时间开发一些基于Linux平台的程序。我已经完成的一项工作是为Linux编写两个3D驱动程序，即在这个平台上进行大量的编程。作为一名开发人员，这对我非常有用，因为我做了大量高层次的、API级别的编程工作，但是我应当继续深入到系统底层。通过开发设备驱动程序，编写一些深入到硬件内部的部署级程序可以开阔我的眼界，让我可以从整个流程的角度看待各项工作。有很多程序员只知道顶层的开发方法，而不知道程序工作的基本原理，这主要是因为他们无法“看到”系统的内部结构。 

            我正在考虑着手的另外一项工作是(因为我喜欢清楚地从最高层到最底层的所有技术细节)花一些时间开发我自己的网络堆栈，以便进行研究和学习。我还做了一些我想要尝试的试验，以便在串行驱动程序和分组驱动程序的层次上了解操作系统实际上为路由时间和排序所支出的开销。我希望从我们通常用于通信的协议层下面获得一些信息。 

            FS: 仅仅是在Linux平台上，还是也包括Windows和Mac平台？ 
            John: 
            关键是在Linux平台上开展这些工作更加方便，因为你能够获得你所需要的所有信息。尽管Linux还不能取代Windows成为主流的桌面操作系统，但是它的确具有一些独到之处。 

            吸引我这样做的原因是有人为Matrox显卡编写了一个Linux驱动程序。我对它进行了测试。显然它不能兼容Quake 
            3。因此我决定将它下载下来仔细研究。我对它的出色的工作机制留下来深刻的印象。尽管它的速度不快，但是它几乎可以说是一个功能齐全的、高质量的程序。但是它在纹理的交换方式方面存在明显的缺陷。他们交换的是最近使用的纹理，而不是最少使用的纹理，因而你可以在屏幕上看到明显的失真。 

            我很清楚它的工作方式，因而我想“太好了，它提供了源代码。”因此我决定下载源程序、进入CVS库和所有文件，按照我的想法改进代码，发现程序缺陷，并将其消除！整个过程非常明确。 

            由此得出的结论是，Apple的驱动程序曾经也存在相同的缺陷。因此我们可以在两个驱动程序中发现相同的缺陷，但是对于Linux程序来说，我可以直接进入源程序，消除这个缺陷。尽管在很多层次上仍然存在不少障碍，但是具备这种能力非常重要。从根本上说，如果你在使用一个源码完全开放的系统时遇到了一些问题，你可以花时间自行解决这个问题。你不需要等待别人的帮助。你不需要低声下气地寻求帮助，也不需要等待补丁发布，而通常这样做会降低时间的利用效率，但是如果某个问题真的让你头疼不已，你可以直接查看源代码，解决这个问题。这会让人感到非常振奋。
 
 
             关于Linux的其他问题
            FS: 这就是你对待问题的态度——亲手解决问题。你并不想等待别人来发布一个升级程序，而是愿意自己动手。 
            John: 
            是的，这就正是为什么在我对网络或者其他问题进行研究时，我更愿意使用Linux平台。如果需要，你可以取出操作系统的某些部分，告诉自己：“好的，现在我想要把这一部分完全删除，因为我想要做一个试验。”你可以获得自由发挥的空间。 

            我认为，在未来几年中，软件的可用性将日益得到重视。有很多经济趋势与此有关。你将看到价格低于500美元的PC和90美元的Windows使用许可。如果人们只想执行一些非常基本的任务，他们很可能希望获得一个免费的操作系统。 

            Linux界有很多疯狂的支持者，他们的观点有时缺乏足够的理性。但是，在关于Linux的实际优势的宣传中的确存在着一些真实情况。 
            FS: 你很关注技术，而且你鞭策自己不断进步。但是你是否考虑过找一个上司来帮助你学习新的技能？ 
            John: 
            我知道在某些工作上聘请管理人员可以带来很多好处。我们在第三季度末聘请了Graeme来帮助我们管理部分业务。但是它并没有对我的工作方式产生实际的影响，因为Graeme还没有蛮横到干涉每项具体的工作。事实上，我自己对工作的安排往往好过大部分管理人员给我制定的工作计划。 

            我也意识到了我的个人组织能力的局限性。我会将几千件事情放在我的任务清单上，而且常常是从头开始对所有事情进行排序。我的确认为如果有个人的主要工作就是确保我知道和了解所有这些任务的重要性就好了，因为每个人的组织能力都存在一定的不足。你自己可能不会这样做，但是有些事情就是因为你一直不愿意去处理而最终泡汤。我已经意识到了让某个人帮我安排工作的好处。 

            最近我在找一个人来对一些程序——尤其是Linux驱动程序——的OpenGL性能进行兼容性测试。我为此编写了大量的程序，我也尽量设法将这件事负责到底，但是我知道我需要采取多种方法来实现我的目标。我希望编写一个完美的程序，但是我也深深意识到，在我的有限的时间里，我不可能做到面面俱到。 

            有时候有一个专门负责帮助你的助手会带来很大的方便。但是这对我来说仍然只是一个理论上的问题。我相信这样做会有所帮助，但是还没有看到实际的效果。 

            Carmack作为学生 
            FS: 出了组织能力以外，能否将一位管理人员视为老师？你觉得可以从谁身上学到对自己有用的知识？ 
            John: 
            实际上，我几乎向每个人学习。这是十几岁时的我和现在的我的主要区别之一。当我十几岁时，我的想法是：“我比我周围的人都聪明，因此我完全不用理会别人说什么。”我在大学的几个学期中都是如此。现在回想起来，我觉得我采用了错误的处世方法。是的，也许我的确比教授聪明，但这并不意味着我不能从他身上学到对我有用的知识。 

            现在我的处世方法是，我愿意向与我一同进行编程的任何同事身上学习知识。我很珍惜我与Brian 
            Hook一同工作的时光。我从他身上学到了一些更好的C语言编程标准和如何更加严格地使用struct和const——而我过去并不这样做。这对我非常重要，因为我通过他提高了自己的技术水平。另外还有Graeme——我看到他从Java库中迅速地找到自己所需要的信息——而我往往是从头做起，到处查找这些信息，因而花的时间比他长得多。 

            某人并非要成为一个“更好的”开发人员或者程序员才有值得你学习的知识，这是我在过去10年中获得的一个非常重要的经验。到处都有值得你学习的知识。如果你拥有正确的学习态度，那么把自己放在一个信息丰富的环境中会对你很有帮助。如果你想从任何地方获得你想要学习的知识，而不是寻找一个将所有信息都集中到一起的有用信息 
 
             “宝库”，你必须能够从你所能接触到的任何地方搜集对你有用的信息。 
            在开发Quake的过程中，我们聘请了Michael 
            Abrash。我为此激动不已，因为我曾经通过他以Dobbs博士为笔名发表的很多文章中学习了大量基本的PC编程技能——包括汇编语言和图像编程。因此我对能够于他合作感到非常高兴。我从他那里又学到了很多知识，但是有趣的是，我有一阵子感到非常不舒服，因为他在编程方面对我非常顺从。Michael的知识非常渊博，但是我的长处是学习新知识的能力很强。
            因此，我几乎从我合作过的所有程序员身上都学到了很多知识。 
            FS: OK，你刚才提到从周围搜集有用的信息。你怎样看待非技术性的信息来源——例如书籍和电影？ 
            John: 我这几年来最喜爱的书是由Vernor Vinge撰写的《A Deepness in the 
            Sky》。在电影方面，我不知道我所说的是否有参考意义。我欣赏了大部分好看的电影。《玩具总动员2》非常出色——我很喜欢这部电影。 
            FS: 《黑客帝国》呢？ 
            John: 
            《黑客帝国》非常精彩。我喜欢所有精彩的科幻、动作和类似的电影。我不是很喜欢意义深刻的电影。我看电影的目的纯粹是为了娱乐。有些电影实际上改编自我们开发的游戏。我们的游戏相当于计算机游戏界的施瓦辛格电影。 

            Quake 和简洁 
            FS: 你认为人们为什么喜欢Quake 3? 
            John: 我们希望通过Quake 
            3达到的目的就是让你可以在玩游戏时全身心地投入其中。对于华丽设计或者其他特点的吹嘘，以及试图在游戏上强加一个传奇或者故事的做法毫无意义。一个游戏的真正价值在于让你在玩游戏时感到有趣。关键并不是击败游戏对手或者完成某项任务，而是要让战斗真正有趣。 

            必须有些让你想要采取行动的任务。人们不会因为玩垒球游戏而真的去玩垒球；必须有一个本身很有意思的战斗。我认为我们在这方面做得不错。我们期望，并且的确从我们的拥护者那里得到了大量的反馈信息。 

            肯定有些玩家希望玩更加复杂、更加具有挑战性的游戏。对于游戏来说，这是一个可行的发展方向，但是它可能会导致游戏内核的发展停滞不前。你可以在玩飞行模拟游戏时体会到这一点，因为这些游戏要求你在开始游戏之前阅读漫长的使用手册。而在过去的飞行模拟游戏中，你要做的就是跳进飞机、起飞和射击。这些游戏可以给玩家带来真正的快乐。而在有些严肃的模拟游戏中，你必须让自己相信你真的达到了娱乐的目的。 

            也可以像这样来开发第一人称射击游戏，即要求玩家了解现在发生的情况，各种工具的使用方法，以及各种战略等——而玩家并不想要知道这些，他们希望的只是坐下来玩游戏。也许有很多人喜欢这样的游戏，但是我并非如此。我没有时间学习游戏的各种知识。我从来不玩那种需要学习大量复杂的知识的游戏。我只喜欢玩一些简单的、迅速上手的游戏，它们让我可以立即进入游戏，享受一段美好时光。我认为与我一样的游戏玩家是上面那种喜欢复杂游戏的玩家的五倍以上。
            FS: 你最近一次玩超过2小时的、非id出品的游戏是什么？ 
            John: 很可能是Nintendo 64平台上的F-Zero X ——一款赛车游戏。 
            FS: 你是否考虑过开发一款赛车游戏？ 
            John: 我们曾经在推出Wolfenstein 之后讨论过这个问题。 
            当时我正在研究一些三维象素-landfield技术，我们制作了一些汽车行驶的简单演示。但是我们从来没有采取任何措施来将这个想法付诸实施。但是如果我们真的开发一款赛车游戏，那肯定也属于非常有趣的赛车类游戏——例如F-Zero游戏，而不是非常严肃的赛车模拟游戏。这里我要再次指出，游戏界有很多有效的发展途径，但是我有我自己的个人爱好。我的爱好恰好让我们既可以开发出成功的游戏，又可以让游戏具有我所认为的真正的娱乐性。 
 

            Id公司的下一款游戏 
            FS: 你认为你的个人爱好并不是开车，而是火箭发射器？
            John: 
            游戏的目的就是娱乐。模拟游戏从来没有让我获得愉快的感觉，包括飞行模拟、赛车模拟和所有类似的模拟游戏。我知道它们在某些方面具有一定的娱乐性。它肯定不会像我说的：“这些游戏非常枯燥，所有人会喜欢它们”。但是，它们并不是我喜欢的游戏类型。 

            在我刚刚喜欢上RGP游戏时，我的生活因为其他一些事务而变得越来越忙碌，因而我没有很多时间用来玩游戏。我一直都很喜欢简单的卷轴游戏。尽管从Gauntlet到Quake 
            3，它们已经发生了很大的变化，它们的基本理念仍然没有改变——你需要四处奔跑、打败敌人、拾起武器、及时进入下一关。这是一个从根本上非常有效的、核心的、首要的游戏元素，我对将相对较为类似的游戏(例如Quake、Quake 
            2和Quake 
            3)制作成具有不同风格的游戏并不觉得有什么不好。就像总有人玩赛车游戏和飞行游戏一样，现在也总是会有各种各样的第一人称射击游戏。我认为我们的每个项目都得到了重要的收获。我们的下一个游戏可能会采用一种完全不同的方式，因为并不是公司中的每个人的想法都与我一样。因此下一次我们可能会稍微改变一下我们的策略，但是我们还没有做出最终的决定。 

            FS:它仍然是一款第一人称游戏吗？
            John: 
            它很可能仍然是一款第一人称游戏，但是它不一定是一款动作游戏。Graeme和我一直在讨论很多游戏的设计创意，并且探讨了我们目前拥有的各种选择，但是我们还没有准备好讨论任何细节。它很可能是一款第一人称游戏——这几乎是肯定的。 

            FS: 
            我刚才在想，如果id进入RTS或者其他类型的游戏领域，可能会出现非常有趣的情况——这就像Blizzard从RTS转向开发动作RPG一样。
            John: 
            我不是一个真正的实时战略游戏玩家。实际上，我从来没有真正坐下来玩过一款SLG游戏。这不是我喜欢的类型。它与第一人称游戏完全不同——后者是最有现场感的游戏。 

            实时战略游戏是最没有现场感的游戏之一。你只是指挥你的军队，而不是你自己在游戏中冲锋陷阵。我想我们还是会继续开发第一人称类游戏。从第一人称游戏转向第三人称游戏只是一小步，但是我认为肯定有其他一些公司更加擅长开发第三人称游戏，例如那些在开发指挥战略方面更具实力的公司。
            与游戏行业的很多人不同，我并没有在计算机上制作电影的想法。而正是这种想法导致了很多公司陷入困境。有些游戏设计人员认为他们是导演，而我认为你应当摆正自己的位置。我只是一名游戏设计师，而不是一名电影导演。这也是促使很多公司转向第三人称游戏的原因。第三人称显然更适于显示人物动画这样的特效。Steed肯定希望开发更加重视动画的游戏，但是这可能并不是我们的下一款游戏的开发重点。我们还没有最终决定，但是我肯定将继续开发第一人称游戏。
            关于游戏行业 
            FS: 
            你把在计算机上制作电影视为“很多公司陷入困境的原因”的说法很有意思，因为有很多3D显卡公司——例如3dfx和Nvidia——实际上将“把好莱坞引入台式机”作为他们的宣传重点。 

            John: 这个现象存在很多有趣的问题—— 
            一个是以最高的质量发挥今天的3D引擎的威力所需要的人力正在迅速接近好莱坞所需要的电影布景人员的数量。就像现在，Quake 
            3远远没有真正地达到我们所能制作的视觉效果的最高水平，但是只有这样我们才能保持足够快的开发速度。 
            但是如果有人根据这个圣诞节推出的产品了解了今年的技术水平之后说：“我想要制作出视觉效果最惊人的、最接近电影的游戏”，那么他可以制作出远远超过人们目前所看到的视效水平的游戏。相关的技术都是现成的。这就是过去一年中游戏行业的发展趋势，尤其是一些特殊的效果，例如各个层次的完全纹理渲染，需要场景设计人员加入进来，以不同的方式设计他们的场景，以及利用模型构建所有这些特效。这样的努力现在可以被用在计算机游戏中。而过去并不是这样。 
 
 
            在我们开发Doom和Quake时，我们并没有能力投入如此多的人力。如果你需要设计一个房间、一条走廊和另外一个房间，你应当采用的方法是：走廊、模块、模块、天花板。这就是你所能做的一切，因此我们所能开展的工作受到了严重的限制。 

            FS: 你总是支持以规模较小的团队开发游戏；这是否意味着孩子们可以在自家的车房中和伙伴们一同开发游戏？ 
            John: 
            我们还没有充分地发掘出所有可能的游戏种类。很多人在很多方面对游戏行业有所不满，而事实上的确很多发行商并不喜欢发行创意新颖的游戏。来自Definition 
            6的Chris Hecker 
            一直在用多种方法推广物理游戏；他开发了一些新奇的游戏。他所开发的游戏使用了一个新颖的创意。他还制作了一个简短的游戏演示。这个游戏将物理作为它的核心原理，但是它并不是像“让我们将物理加入一个第一人称设计游戏”一样。它是一个非常独特的游戏。它采用了一个很好的游戏设计，而且与物理学密切相关。但是发行商对它一点都不感兴趣。 

            这的确非常糟糕，但是与此同时，我们也可以从其他一些事情上看到一些积极的迹象，例如有些人通过在互联网上销售他们所开发的一些简单的小游戏而赚了大钱，例如每年通过被下载的游戏获得几千美元的收入。我对此感到非常振奋，因为我们可以清楚地看到，有些人可以通过开发主流之外的游戏赚钱；这种情况因为互联网而成为了可能。 

            我们在公司创建早期以共享软件的形式获得了成功。通过最初的Keen三部曲，我们每年的收入达到了10万到15万美元。通过第二个三部曲，我们每年借助共享软件获得的收入达到了50万美元。这还是在我们进入正式的商业销售市场之前。现在看来可以比当时做得更加出色。这的确很有意思。但是由于货架上需要占用成本费用和货架空间，发行商并没有兴趣发行创意新颖的游戏。我确信肯定有一些新的游戏种类正准备崭露头角，但是面临着一些阻力。 

            Id不是一个发行商 
            FS: 你对Halo感兴趣吗？ 
            John: 
            我看过它的影片；看起来非常出色。现在的问题是无法根据屏幕截图来判断一个游戏的好坏，因为任何一个不够胜任的渲染引擎都可以渲染某个特定的场景。关键在于各个对象能否无缝地连接到一起。Bungie拥有很多杰出的游戏设计人才。他们从事游戏行业的时间和我们差不多。他们很多年来就像是id在Mac平台上的影子。但是现在他们已经走在了前面，并在PC平台上取得了一些重要的成果。他们表现得非常不错。 

            FS: 再回到开创新的游戏种类和来自发行商的阻力的话题，你是否有兴趣帮助推广新的游戏种类，例如提供一些资金来发行这些游戏？ 
            John: 
            我肯定不想成为一个发行商。Id内部就这个问题讨论了很多年。五年以前，所有的游戏开发公司都希望成为发行商，因为当时有很多小型发行商。后来这些小型开发商逐渐被合并为少量大型发行商。我们就这个问题讨论了很长时间，而且我们自己发行了最初的Quake共享软件，但是当与发行商达成协商之后，我们很可能损失了一些利润，因为发行商的业务管理往往相当糟糕。但是最后所有人都达成了一致意见——尤其是在我们看到很多发行商的合并和倒闭之后——做一个开发商比做一个发行商好得多。因为软件开发商是这个行业中比较清楚的部分，你只需要交付CD，再通过邮件接收支票。但是，作为一个发行商，你需要处理行业中的很多你根本不想接触的混乱部分，例如代理商在取走并售出你的产品之后付费等。我一点也不想接触这方面的业务。 

            FS: 或者利用你的影响力来说服一些发行商，你知道，也许你应该利用这个机会。 
            John: 
            我不会投入太多。我会对这样的事情临时发表一些意见，但是我不会对一些我知道没有足够的时间和精力来努力的事情提出承诺。事实上，这对于我保持对主要工作的专注非常重要。我愿意不去理睬大量的琐事。这一点非常重要，因为如此多的事情都可能需要占用我的时间。可以从很多面临类似处境的人的生活中看到这样做的重要性：整天都有人不停地找他们，从而使得他们无法开展任何工作，因为想要达到某个目的的人会给他们拨打电话和发送电子邮件——对他们进行访问，或者请他们提出一个业务建议。 
  
 
            有时候我会因为没有完成更多的工作而感到内疚。尤其是在即将到来的一年中，有很多不同的硬件设计工作需要完成，而且每个人都没有一个明确的发展方向。我告诉自己，我应当参与到开发工作中，帮助所有人达成一致意见，因为我的地位使得我比较适合扮演这样的角色。微软在很多方面很乐于听从我的建议，很多硬件公司肯定也愿意这样做。他们对我存在一定程度的尊重。但是在开发Quake 
            3期间，我没有时间来从事这方面的工作。 
            现在我可以四处宣传一些想法，但是我深知，即使是现在，我也不能完全投入这项工作，因为尝试并带领整个行业沿着我所希望的方向向前发展实际上是一个全职的工作。我还没有狂妄到认为世界没有我就转不了。因此我想要说的是，我会尽量提供帮助，但是我不会全身心地投入这项工作。 

            关于Trinity
            FS: 让我们换个话题，我读到的一篇文章提到在Quake 3成功推出之后，你准备花更多的时间研究引擎。 
            John: 我目前正在开展多项引擎研究工作。 
            FS: Trinity是其中之一吗？我想人们一直对“Trinity”有些迷惑不解。 
            John: 
            我一直不知道为什么每个人都对Trinity感到迷惑不解。在推出Quake之后，我开始研究新的渲染技术，人们都将其称为“下一个引擎”或者其他名称。Michael 
            Abrash建议我们采用Intel的做法：用一条附近的河流命名你的下一个项目。达拉斯有条名为Trinity的河，所以我们就下一个项目的名字取为“Trinity引擎”。当然，我们最终没有将其用于某个项目，因为Quake 
            II是Quake I的续作，而且我没有在Quake 
            II上使用[Trinity]，因而没有任何一个项目采用了这项技术。刚才我们谈到了我当时所做的工作。在开始开发Quake 
            III时，我针对不同的渲染技术编写了六个不同的研究引擎。 
            但是这仍然只是我所从事的研究工作。其中包括2个三维象素项目，1个空间扭曲项目，1个照明图项目，其中的一部分工作成果后来成为了Quake 
            III引擎。 
            有一件事一直是id和我的技术指导工作的真正实力之一。你可以看到一些公司紧紧抓住某个聪明的创意不放；有些你可能耳熟能详的游戏则是以一个创意为核心进行游戏开发。而我并不受限于某个特定的创意的束缚。正如我刚才所说的，在开始开发Quake 
            III时，我有六个不同的任务需要完成。我观察了所有这些任务，然后对自己说：“这些任务更加简单明了。”但是我们为Quake 
            III所做的工作实际上是很多方法中的一种比较正确的方法。我现在还有很多任务需要完成。但是没有人会在上面贴上魔法标签，所以我需要亲自评估所有这些不同的任务。 

            三维象素和曲线 
            FS: 
            你刚才提到了三维象素，而且你正在开展这方面的研究。你是否认为3D硬件公司应当关注三维象素加速？你怎样看待已经推出的三维象素游戏，例如“三角洲部队”？ 

            John: 
            三维象素开发？我过去编写过一些三维象素引擎。实际上Shadowcaster——即Raven的最初名称——的早期版本中就曾经使用了三维象素地面。但是在我们重新编写该程序，以便更多地使用多边形时，我们将三维象素地面删除了。用三维象素技术显示对象可以带来一些实际的好处，因为它可以通过多种方式为您提供完整的纹理和轮廓细节。我在刚开始开发Quake 
            III时编写了这两个三维象素引擎，我当时认为我可以让它们完全通过软件运行，但是它只能提供相当低的分辨率。根据你所能达到的水平，以及硬件多边形的生成速度，在这种情况下并没有必要使用这项技术。 

            我分析了内存存取模式；你可以用硬件做一个三维象素光迹追踪器，它所使用的硬件资源远远少于我们现在在进行各种三角形光栅处理时实际所用的资源。我认为它在很多情况下可以提供更加具有吸引力的视觉效果。但是它的确很难理解，因此我不太愿意向人们推荐这样的技术。我知道我做了一些介绍性的演示，但是PC行业能达到现在的硬件水平的根本原因是我们都可以借鉴SGI这个例子。我们拥有“这显然可以发挥作用，你看他们已经做到了”的说法的实际证据，因而问题就在于如何挑战并最终超过他们的成绩。 

            如果要推荐某种全新的技术，有人会说：“你应当让你的工厂生产三维象素芯片，你应当尝试这项技术，并向它投资几百万美元。”我不愿意这样做，因为我们并没有一个完整的证据来表明我们在开发引擎时有必要采用这项技术，也不能证明它可以带来足够的渲染改进。如果有人真的做了一个三维象素开发工具，你可以得到它的深度值，并将其与现有的三角形混合，这可能会是一个有趣的中间步骤，但是坦白的说，我并不认为它会占用如此多的硬件资源。由于现在每个人都在想方设法让自己的产品独树一帜，所以可能会有人用这种技术作为宣传的噱头，但是肯定仅此而已，因为他们还不知道具体怎样使用这项技术。 

            我认为现在有些非常具有潜力的技术，但是我并不能肯定这就是未来的发展方向，因为尽管这些技术适用于环境的开发，而且你可以将它们用于一些出色的应用，但是还不清楚它们是否适用于角色的开发。你可能会说：“也许你必须用一个变形矩阵构建这个模型，然后当你对它进行Raycast渲染时，让光线在接触变形网格时转向。”但是我还没有编写过这种软件版本。只有在我可以提供一个显示这种技术的工作方式，而且它看起来比你直接可以实现的效果更好的情况下，我才会向别人推荐这项技术。我现在还没有时间来做这件事情，因为我有一些迫在眉睫的研究任务需要完成。 

            但是我认为这项技术具有一些重要的潜力，有可能会成为一个有趣的发展方向。我现在真正想向所有人介绍的技术是更高阶的表面渲染，包括曲线、细分表面等。现在每个人都对这些技术非常感兴趣。在使用了两年时间之后，我发现它们并不像宣传得那样出色；它们存在不少问题。你直接从外面往往发现不了，对于一个开发人员来说，必须要深入内部才能看到这些技术的本质。 

            如果你曾经读过相关的研究文献，了解贝赛尔曲线的工作方式，你可能会想，哦，这项技术非常出色，这正是我们在三角形单元之后的前进方向。你并没有意识到所有的“实际”问题，例如使用无效的、标准的，但是退化的边缘。你不能随意地划分一条曲线——除非将其提高到两侧的平面。你不能通过调整其他部分连接两个交叉点。所有这些细微的不足最终会造成很大的不便，尤其是在比较困难的情况下，你很难全面地了解发生问题的环节。三维象素技术也存在所有这些问题，这就是我为什么不愿意上台演讲，描绘未来的远景，因为很多技术从表面上看来很出色，但是当你深入到它们的内部时，往往会得出相反的结论。 

            对竞争的看法 
            FS: 既然你打算重新开展研究工作，那么这是否会对id的下一款游戏的推出时间产生一定的影响？ 
            John: 这取决于我们最终决定下一步采取什么措施。我目前正在开发的两种技术都适用于现有的Quake 
            3框架，因此这些新技术可能会被加入到下一个产品中。
            目前我们得到了一个非常重要的机会，即我们可以使用这个牢固的、稳定的、可扩展的、灵活的引擎，从而将我们的开发重点放在游戏设计上，而不需要考虑引擎的开发。。。 
            从一位管理人员的角度来说，这无疑非常有利。但是，如果我们这样做，我现在正在开发的技术很可能不会在三年、四年甚至更长的时间内被用于新的产品。对于技术的发展来说，这是相当长的一段时间。因此我们需要一个真正强有力的激励来促使我们将一些新技术加入到下一个产品中。 

            FS: 你是否通过玩其他游戏和观看竞争对手的产品来开展研究工作？ 
            John: 我经常玩Unreal，将来我可能会喜欢玩Unreal 
            Tournament——尽管我现在还没有玩这款游戏。另外，我还会玩很多演示版的游戏。我不会进行一次真正彻底的调查，玩遍市场上的每款游戏。通常我只是在别人玩最热门的新游戏时旁观一下。而我不会花很多的时间玩其他的游戏。当然，我玩Quake3的时间超出了其他任何一款游戏。 
            FS: 公司中是否有专人负责这项工作？ 
            John: 
            Christian和Graeme会玩大部分新游戏。过去是Brandon负责玩每个游戏。当他在id时，所有信息都会从他那里过滤一下。Tim也经常出于一些研究目的玩游戏；Tim在浏览其他游戏方面表现得相当尽责，而Graeme和 
            Christian 玩其他游戏的主要目的只是娱乐。 
            Carmack的研究 
            FS: 你能否简单地介绍一下你的研究内容？ 
            John:我现在正在开发的一个渲染引擎技术是一个更好的照明模型。Quake 2 
            在计算中添加了发射性照明，它可以带来真实的光线反射效果，但是很多人实际上并不喜欢这种技术，因为它消除了一些阴影，从而让更多的对象陷入黑暗之中，尽管这比较符合实际情况——很多人都喜欢更为明显的阴影。在Quake 
            3中，我们重新只使用了一个直接照射灯，这在一定程度上是因为我不想在曲线上进行有限元放射计算。另外一项技术将让设计人员可以在任何地方渲染纹理和划分轮廓，从而让我们可以手动改进对象的显示效果。因此，主要有两个研究方向。实际上，它们可以被结合到一起，或者共同使用。它们都给我带来了一些有趣的技术难题。这些技术可能会在我们的下一款产品中得到展示。 

            我的其他一些研究内容与游戏引擎无关。我正在利用Web摄像头进行一些视觉研究，例如一种头部跟踪装置。我可以利用这种装置，在游戏中加入一些有趣的内容。例如当你来回摇你的头时，你在游戏中扮演的角色也会做出同样的动作。或者像一种支持全息照相的窗口界面，你只需要移动你的头，就可以改变你的形象。我并不认为Web摄像头用于足够快的速度，在没有显著延时的情况下实现上述目标，但是这仍然是一个相当有趣的技术。你可以利用面部表情等，将它提高到新的水平。 

            我认为这些技术的应用将会超过我的想象。所有短时间的不连续都是由于输入/输出设备的变化所引起的。当人们开始用鼠标进行各种操作时，事情发生了变化。我认为“计算机视觉”已经具备足够的实用性，足以对对象产生“鼠标式”的影响。毕竟，有些事情只能通过鼠标完成，而不能依靠键盘。这仍然处于自由猜想阶段。
            现在出现了一些有趣的应用，因为我们现在运用了足够强大的CPU运算能力，可以进行一些相当复杂的计算。与很多图像技术不同，它还有很多尚未解决的研究问题。很多人正在研究这些难题，但是我们没有“SGI实例”来知道怎样将对象组合到一起和提高运算速度。 

            我所感兴趣的最后一个研究方向是实现更加通用的3D技术，例如能够在3D世界中利用其他的渲染工具(例如HTML)开展工作，以及能够建立不与某个特定游戏相关联的小型网络空间。我认为我们可以构建一个基础设施框架。我们可以开发一款第一人称设计游戏，但是框架具有足够的通用性，因而我们可以用它完成其他任务。 

            所有现有的软件显然都是针对第一人称射击游戏而设计的，但是人们以后可以利用这些技术执行其他一些有趣的任务。通用化总是要付出不菲的成本。你可以通过技术的专用化提高它的工作效率，但是在某个转折点你可能会发现通用化的成本并不是很高，而拥有一个更加通用的平台所带来的好处更加显著。我认为3D游戏目前正处于一个这样的转折点。
            现在的我们与两年前大不相同。当时我们仍然需要考虑每一个很短的帧来提高一点点性能。由于硬件加速的发展——尤其是轮廓加速的实现，以及速度更快的CPU和容量更大的RAM的出现，这种情况已经不复存在。我认为我们的通用平台的速度可以达到专用版本的90%以上，同时可以利用这个平台处理大量其他的、有趣的任务。 

            综合性问题 
            FS: 你希望建立一个永久性的Quake世界，让人们可以在其中进行对话和交流吧？  
             John: 
            是的，甚至不一定与Quake有关。我认为在利用介质通信方面有很多有趣的工作需要完成。你会看到人们互相交流，在一个服务器上会面等。这方面有很多潜在的发展方向。我不会将其称为虚拟现实，因为VR已经成了一个与死亡和毁灭联系在一起的名次。从来没有一家成功的VR公司，但是我认为其中很多公司失败的原因都是当时并没有相应的技术来实现他们的创意。在很多情况下，创造力和创新精神都会受到技术发展的限制。 

            Doom就是一个典型的例子。我们用了很多的聪明、才智和创造力才开发出了Doom，但是所有这些聪明才智在五年之前并不能产生任何作用，因为当时的技术限制使得人们不可能开发出像Doom这样的游戏。有些时机是适合出现新的创新技术的。 

            我认为在未来几年中，将会出现很多这样的创新技术，例如3D界面的通用化。每个人都用一种含糊的、空想的方法预言互联网和Web在未来的某个时候拥有一个3D界面。但是没有人提出真正实现这个目标所需要的具体细节。现在可能是实现这个目标的时机，但是也可能不是。 

            我很关注这些研究方向，而且我将从事所有这些研究工作。最终我将把那些最有前途的技术研究到底。 
            FS: 你是否建议年轻人上学？ 
            John: 
            如果你是为了正确的理由上学，那么学校将是一个很好的学习知识的场所。大学可能是一个信息极为丰富的环境。我现在回想我的大学生活，会觉得我浪费了很多宝贵的时光。我当时应当使用他们的图形工作站和其他设备学习知识。 

            如果你只是为了获得一个学位，以便找到一份满意的工作，那么我并不支持。如果你上学是为了结识聪明人、拓展知识面和学习新知识，那么我完全支持。有些人在大学的收获比我上面列出的多得多。至于我，我一直都是那种只会看产品手册的学生。我喜欢这种学习方式，但是并不是所有人都喜欢这样。我并不认为大学是一个不好的地方，但是我并不支持这样的观点：“你必须上大学，这是唯一的成功之路”。原因很简单，它并不是唯一的成功之路。 

            我认为，至少对于一些年轻的、发展迅速的行业(例如互联网和游戏设计)而言，才能和一份表明你的工作经验的简历比学位更加重要。我从来不问别人“你是否有一个学位？”我更关心的是“你做过什么？”如果要从坐在课堂里参加考试或者在家里编写游戏程序来证明你所拥有的天赋之间进行选择，我认为后者不失为一条合理的成长道路。 

            FS: 最后一个问题——你现在玩的是什么游戏机？ 
            John: 我在家经常玩的游戏机是Nintendo 64，但是除此以外我们还拥有Playstation、Saturn和其他一些游戏机。 
            Firingsquad 和 Gamers.com 
            非常感谢John和Anna抽出时间接受我们的访问。我们的这篇文章得到了广泛的好评，我们希望在不久的将来访问您所喜爱的其他程序员。请到我们的留言板上发表您对本访问的看法。
            [责编：郭胜民] 
 

1，Windows应用程序中一定要有WinMain函数，用来完成某些特殊的任务，其中最主要的是创建应用次序的主窗口。

2，DOS下，所有次序的目标模块在创建过程中都被静态连接起来。而Windows允许动态连接,即一些特定结构的库（DLL）可以在运行过程中被装入和连接,并且被多个应用程序共享。

3，项目是一些相互关联的源文件的集合，这些源文件经过编译、连接，然后被组合在一起形成可执行的Wwindows应用程序或DLL。

4，几个重要Developer Studio创建的中间文件：
CLW （支持ClassWizard ） DSP （项目文件）
DSW （工作空间文件）  NCB （支持ClassView)
OPT （保持工作空间的配置） PLG （建立日志文件）

5，AppWizard是一个代码生成器，它会按照用户通过对话框指定的特性、类名、及源代码文件名来产生Windows应用程序工作架构。AppWizard所产生的代码只是一些最基本的代码，它完成的功能完全由应用程序的基类所决定。

/**************************************/
第二章：Microsoft基本类库应用程序框架

1,按照惯例，MFC库类名用大写“C”打头。

2，类CMyApp的对象theApp就代表一个应用程序。当运行该应用程序的时候，WINDOWS自动调用程序框架内部的WinMain函数，WinMain函数会去查找该应用程序的全局构造对象(theApp)，该对象是有CWinApp类派生类的对象。C++中，全局对象在主程序被运行之前就已经构造好了。

3，当WinMain发现该应用程序对象(theApp)时，会自动调用虚拟成员函数CWinApp::InitInstance()，该函数会进一步调用相应的函数来完成主窗口的构造和显示工作。由于基类CWinApp中不知道我们实际需要的什么样的窗口，所以我们必须在派生出的应用程序类CMyApp中重载InitInstance()函数（CMyApp::InitInstance()），由多态性，当调用CWinApp::InitInstance()时候，会自动转向MyApp::InitInstance().

4，WinMain函数调用完InitInstance()函数后，就调用CWinApp::Run函数，CWinApp::Run函数被隐藏在基类中负责传递应用程序的消息给相应的窗口，从而维护应用程序的运转。

5，关闭应用程序（对单一框架程序来说），首先CMyFrame 对象被删除，然后退出Run,进而退出WinMain,最后删除CMyApp对象（theApp）。

6,一些Windows类库在基类为鼠标事件消息以及其他一些标准消息定义一些虚函数，如果需要，派生类会对这些函数进行重载。
MFC库应用程序框架没有采用虚函数来处理Windows消息，而是通过一些宏来将特定的消息映射到派生类中相应的成员函数上。（原因：P21。C++类对程序中用到的每一个派生类都要求有一张虚函数分发表VTABLE,在BTABLE中每个虚函数都需要有一个4字节的入口项，而不管该函数会不会在派生类中被重载。）
MFC消息控件函数要求提供函数原型，函数体，以及在消息映射中的入口。

7，文档-视图结构将数据从用户对数据的观察中分离出来，这样就允许对同一数据可以有多个视图。
MFC库应用程序中，文档和视图是由C++类的实例来描述的。
文档基类代码通常和FILE OPEN，FILE SAVE菜单项关联，而派生文档类则一般用来完成对文档对象数据的实际读写工作。
视图基类通常表示一个包含于框架窗口中的窗口，而派生视图类则常用来和稳当类相联系，负责应用程序的显示和打印机I/O。
派生视图类及其基类共同处理WINDOWS的消息，而MFC库则协调文档，视图，框架窗口，以及应用程序之间的相互作用关系，这种协调多用虚函数来实现。
文档对象既可以与一次可全部读入内存的磁盘文件相关联，也可以同数据库相关联。
 

/********************************************/
第三章：从“Hello,world!”着手学习AppWizard

1,视图：从用户角度看，视图是一个普通的窗口；从程序员角度看，试图是一个从MFC库中CView类所派生的类的对象。视图对象的行为完全由类的成员函数和数据成员决定，其中包括派生类的特定成员和基类的继承而来的成员。

2，CEx03aView类最重要的基类是CWnd和CView。CWnd提供CEx03aView的窗口属性，而CView提供它和应用程序框架其它部分之间的联系，特别是和文档及框架窗口之间的联系。

3，视图类中OnDraw成员函数：OnDraw成员函数被设计成一个虚成员函数，每次当视窗需要被重绘时候，应用程序都要调用OnDraw函数。
当用户改变了窗口尺寸，或当前窗口恢复了先前被遮盖的部分，或当前应用程序改变了窗口的数据的时候，窗口都需要被重绘。
当用户改变了窗口尺寸，或窗口需要恢复被遮盖的部分，则应用程序自动去调用OnDraw函数。
但注意，如果程序中某个函数修改了窗口数据，则它必须通过调用视图所继承的Invalidate(InbalidateRect)成员函数来通知Windows，调用Invalidate后会触发对OnDraw函数的调用。

4，WINDOW中不允许直接访问显示硬件，必须通过和窗口相关联的“设备环境”跟显示硬件通讯。MFC中设备环境由CDC类对象来表示。

5，利用Win32 Debug模式 和 Win32 Release模式开发应用程序。
（默认情况不出现BUILD工具栏，可从TOOLS菜单选择Customize项，设置显示Build工具栏，VC6中也可在工具栏上直接点击右键选择Build工具栏）

  Win32 Release模式 Win32 Debug模式   
源码调试 不能   编译器连接器都允许
MFC诊断宏 不能（定义了NDEBUG） 可以（定义了_DEBUG）
库连接  MFC Release库  MFC Debug库
编译优化 速度优化（学习版不能） 没有优化（快速编译）

我们应在Win32 Debug模式下开发应用程序，然后在发布或交付前用Win32 Release模式重建应用程序。in32 Release模式下建立的EXE文件又小又快。

6，诊断宏TRACE宏对监测程序状态特别有用。这些宏要求在允许追踪的情况下才有效，允许追踪是默认设置。
（问题：TRACE宏的应用事例与运行原理。宏TRACE的输出在在哪显示呢？在output输出框下选择Debug项，调试运行程序即可看到TRACE宏输出。）

7，预编译头文件代表了编译器在源代码特定行上进行‘快照’。在MFC库程序中，快照常紧接在#include "stdafx.h"后进行。
文件StdAfx.h包含了MFC库头文件的#include语句。该文件的内容取决于运行AppWizard时候所做的选择。
文件StdAfx.cpp只包含#include "stdafx.h"语句。StdAfx.cpp文件用来在相应项目的目录下产生预编译头文件（PCH文件）。编译开关/Yc只用于StdAfx.cpp文件，导致产生预编译头文件（PCH），而其它源文件的/Yu编译开关使可以使用一个存在的PCH文件。开关/Fp用来指定专门的PCH文件名，默认情况下为相应目标输出文件目录下与项目同名扩展名为PCH的文件。
（ＶＣ６下具体设置参见：［Project Settings属性框］ ［c/c++］属性页［Project　Options］、[Source File Options]项）
（注意：在ＶＣ６　[Project Settings属性框]中查看StdAfx.cpp文件[Source File Options]项时候，可以看到［Project Settings, and /Yc"stdafx.h"］，这里说明一下，StdAfx.cpp文件的［ /Yc"stdafx.h"　］的设置覆盖了[Project Options]设置中的[/Yu"stdafx.h"]）
 

/******************************************/
第四章：基本事件处理、映射模式和滚动视图

1，消息映射：如在视窗中按下鼠标做键，会自动发送WM_LBUTTONDOWN消息，如果要对这消息有所反应的话，需

//{{AFX_MSG(CEx04aView)
 afx_msg void OnLButtonDown(UINT nFlags, CPoint point);//头文件声明消息响应函数原型。
//}}AFX_MSG
DECLARE_MESSAGE_MAP()//头文件

BEGIN_MESSAGE_MAP(CDrawView, CView)//代码文件
 //{{AFX_MSG_MAP(CEx04aView)
 ON_WM_LBUTTONDOWN()//该消息映射宏将OnLButtonDown函数和应用程序框架联系在一起
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CDrawView::OnLButtonDown(UINT nFlags, CPoint point) //代码文件
{
 //event processing code here
}
说明：
为了方便ClassWizard，AppWizard生成了一些注释行。它把消息映射函数原型放在两个AFX_MSG“刮弧对”之间，在AFX_MSG_MAP“刮弧对”之间添加消息映射入口，并在代码文件中给出完整的OnLButtonDown成员函数框架。

2，视图中的OnDraw（）是根据视图当前状态来绘制图象的，用户的操作可以改变这中状态。在完整的MFC库应用程序中，文档的对象掌握在应用程序（视图）的状态。

3，如果用全程变量来保存视图状态，这将在多视图情况下会遇到麻烦；（待体会）

4，CWnd::InvalidateRect函数能够触发WM_PAINT消息，该消息被窗口类如CView映射后，引起对OnDraw函数调用，从而重绘无效矩形区域。
优化窗口的绘制过程：
1）设置的无效区域越小，重画的速度就越快；
2）执行无效区域外的绘制纯属于浪费时间，OnDraw函数可以调用CDC的成员函数GetClipBox得到无效区域大小。
注意：
OnDraw函数不仅仅响应InValidate*之类的调用，它也会在窗口改变大小和窗口显露时被调用。

5，本章重要介绍函数
PtInRect(..);//测试一个点是否落在某个矩形内。
PtInRegion(..);//判断一个点是否落在椭圆（CRgn对象）内//A region is an elliptical or polygonal area within a window.
GetClientRect(..);//获得客户矩形坐标并保持在CRect对象中
SelectStockObject(..);//选择the predefined stock pens, brushes, or fonts到DC中，函数返回先前的CGdiObject 对象指针。

6，在构造函数中对类数据成员初始化。
CEx04aView::CEx04aView() : m_rectEllipse(0, 0, 200, 200)//注意这种初试化方式，m_rectEllipse是CEx04aView类数据成员CRect类对象
{
 m_nColor = GRAY_BRUSH;
}

7，[致WIN32程序员]：
 标准的基于WINDOWS应用程序会首先登记一个窗口类（不同于C++类[补：实际是个_WNDCLASS结构体]），同时在处理过程中，还需要对每个类指定窗口过程（WINDOWS PROCEDURE）。每次应用程序调用CreateWindow建立一个窗口时候，都要指定一个窗口类做为参数，这样就把新建立的窗口和窗口过程函数连接起来了。每次Windows给窗口发送消息时候，这个函数就会被调用（补：消息循环中DispatchMessage(&msg)分派消息到窗口的回调函数处理,OS调用窗口回调函数进行处理），以检查用参数传送进来的消息码，并执行适当的代码来处理该消息。
 MFC库应用程序框架有一个适用于大多数窗口类型的简单窗口类和窗口过程函数。该窗口过程函数会根据参数传进来的窗口句柄，在MFC的句柄映射表（handle map）中查找，从而得到对应的C++窗口对象指针。然后，该窗口过程函数用MFC运行时类（runtime class）系统来决定窗口对象的C++类。下一步，它从由消息分发映射函数生成的静态表中找到消息处理函数，最后用正确的窗口对象调用消息处理函数。

8，映射模式：
1）MM_TEXT映射模式：坐标被映射到象素，X值向右递增，Y值向下递增。可用它来表示[设备坐标]。
CDC::SetMapMode(..)//设置映射模式
CDC::GetMapMode(..)
CDC::SetViewportOrg(..)//设置视口原点
CDC::GetViewportOrg(..)
CDC::SetWindowOrg (..)//设置屏幕原点
CDC::GetWindowOrg(..)
2）固定比例映射模式（MM_HIENGLISH，MM_HIMETRIC ，MM_LOMETRIC ，MM_LOENGLISH，MM_TWIPS ）
固定比例映射模式均X值向右递增，Y值向下递增，它们之间唯一差别是 实际的比例因子。如下：
MM_HIENGLISH   Each logical unit is converted to 0.001 inch.
MM_HIMETRIC   Each logical unit is converted to 0.01 millimeter.
MM_LOENGLISH   Each logical unit is converted to 0.01 inch.
MM_LOMETRIC   Each logical unit is converted to 0.1 millimeter.
MM_TWIPS   Each logical unit is converted to 1/20 of a point（磅）. (Because a point is 1/72 inch, a twip is 1/1440 inch.)
//MM_TWIPS常常用于打印机。        
3）可变比例映射模式：（MM_ISOTROPIC ，MM_ANISOTROPIC ）
这两种模式用许我们改变它们的比例因子和坐标原点。
应用这两中模式，如用户改变窗口的尺寸，绘制的图形大小也会发生响应的变化
具体如下：
The MM_HIENGLISH, MM_HIMETRIC, MM_LOENGLISH, MM_LOMETRIC, and MM_TWIPS modes are useful for applications that must draw in physically meaningful units (such as inches or millimeters). The MM_ISOTROPIC mode ensures a 1:1 aspect ratio, which is useful when it is important to preserve the exact shape of an image. The MM_ANISOTROPIC mode allows the x- and y-coordinates to be adjusted independently
常一起使用的函数：
SetWindowExt(..)//Sets the x- and y-extents of the window associated with the device context.
SetViewportExt(..)//Sets the x- and y-extents of the viewport of the device context. 

注意：
When the following mapping modes are set, calls to SetWindowExt and SetViewportExt functions are ignored:
 MM_HIENGLISH，MM_HIMETRIC，MM_LOENGLISH，MM_LOMETRIC，MM_TEXT，MM_TWIPS
When MM_ISOTROPIC mode is set, an application must call the SetWindowExt member function before calling SetViewportExt.

9，坐标变换：（具体参见P54）
许多MFC库函数只能在设备坐标下工作（尤其CRect类成员函数）。可以认为CDC的所有成员函数都一逻辑坐标作参数。可以认为CWnd的成员函数都以设备坐标做参数。（所有在实际窗口上点击获得的坐标都是逻辑坐标）。在设置了设备环境的映射模式及相应的参数以后，CDC的LPtoDP和DPtoLP函数可以用来在逻辑坐标系和设备做表系之间进行转换。
在CView的虚函数OnPrepareDC中设置映射模式要比在OnDraw函数中要好。
//*注意：
CView::OnPrepareDC
virtual void OnPrepareDC( CDC* pDC, CPrintInfo* pInfo = NULL );
应用程序将在调用OnDraw之前调用OnPrepareDC函数。
（OnPrepareDC在为屏幕显示而调用OnDraw函数之前，或在为打印或打印预览每一页而调用OnPrint成员函数之前。）

10，CScrollView支持滚动条的滚动，但不支持键盘的滚动。通过使用CWnd的ScrollWindow和SetViewportOrg函数，CScrollView类允许将视口原点移到窗口中的任何一个位置，甚至包括窗口区域的上部或窗口的原点的左边。

键盘输入是分两步处理的。OS向窗口发送类如WM_KEYDOWN和WM_KEYUP消息时用的是虚拟键盘码，在消息到达窗口之前，被翻译成WM_CHAR消息，该消息带着正常的键码。

利用对WM_KEYDOWN消息进行响应，对按键分别调用OnVScroll就可以使应用程序支持键盘的滚动。
CWnd::OnVScroll 
afx_msg void OnVScroll( UINT nSBCode, UINT nPos, CScrollBar* pScrollBar );
////
nSBCode：
SB_BOTTOM   Scroll to bottom.
SB_ENDSCROLL   End scroll.
SB_LINEDOWN   Scroll one line down.
SB_LINEUP   Scroll one line up.
SB_PAGEDOWN   Scroll one page down.
SB_PAGEUP   Scroll one page up.
SB_THUMBPOSITION   Scroll to the absolute position. The current position is provided in nPos.
SB_THUMBTRACK   Drag scroll box to specified position. The current position is provided in nPos.
SB_TOP   Scroll to top.
////
The framework calls this member function（OnVScroll） when the user clicks the window’s vertical scroll bar.

11，CView::OnInitialUpdate
virtual void OnInitialUpdate( );
说明：
OnInitialUpdate是视图窗口完全建立后框架调用的第一个函数。框架在第一次调用OnDraw前会调用OnInitialUpdate。
具体参见下：
Called by the framework after the view is first attached to the document, but before the view is initially displayed. The default implementation of this function calls the OnUpdate member function with no hint information .

12，MFC对140种Windows消息直接直接提供了相应的消息控制函数，当然，我们还可以定义自己的消息和相应的消息控制函数。
五种特殊Windows消息：WM_CREATE,WM_CLOSE,WM_QUERYENDSESSION,WM_DESTROY,WM_NCDESTROY.（具体参见 p62-63页。这两页强烈建议看看，这里简要笔记三个最常用最重要的）
1）WM_CREATE消息：
The WM_CREATE message is sent when an application requests that a window be created by calling the CreateWindowEx or CreateWindow function. The window procedure of the new window receives this message after the window is created, but before the window becomes visible. The message is sent before the CreateWindowEx or CreateWindow function returns.
2）WM_CLOSE消息：
当关闭窗口或父窗口被关闭时，Windows都会发送WM_CLOSE消息。可以重新定义该消息响应函数OnClose来完全控制关闭过程。
3）WM_DESTROY消息：
Windows在发送WM_CLOSE消息之后，紧接着就会发送WM_DESTROY消息（响应这个消息的时候，窗口已经消失但还没有销毁）。
（可以响应这个消息来做一些销毁当前窗口后的一些事情，例如再弹出其它对话框发送其他的消息）
 

/**********************************************/
第五章：图形设备接口（GDI）、颜色及字体

1，任何时候当程序需要直接在屏幕或打印机上绘图的时候，都需要调用GDI函数，GDI函数包含了一些用于绘制图形、位图以及文本的函数。

2，Windows的设备环境是GDI的关键元素，它代表了物理设备。每一个C++设备环境对象都有与之对应的Windows设备环境，并且通过一个32位类型的HDC句柄来标识。

3，MFC库设备环境类基类CDC包含了绘图所需要的所有成员函数，并且几乎所有派生类只有构造函数和析构函数不同（CMetaFileDC类除外）。
对于显示器来说，常用的派生类有CClientDC 和 CWindowDC,而对其它设备（如打印机或内存缓冲区），则可以构造一个基类CDC的对象。
对于显示器和打印机设备环境对象来说，应用程序框架会直接将句柄附在对象上；而对其它设备环境（如内存设备环境），为了将对象与句柄相联系，在构造完对象之后，还必须调用一个成员函数（进行初试化）。

4，CClientDC类 和 CWindowDC类
CClientDC( CWnd* pWnd );
//Constructs a CClientDC object that accesses the client area of the CWnd pointed to by pWnd. The constructor calls the Windows function GetDC.

CWindowDC( CWnd* pWnd );
//Constructs a CWindowDC object that accesses the entire screen area (both client and nonclient) of the CWnd object pointed to by pWnd. The constructor calls the Windows function GetWindowDC.

如果构造CClientDC对象，则设备环境的映射区域限于客户区域，不能在客户区域外绘图。原点（0，0）在客户区左上角。
《 如果创建CWindowDC对象，则设备环境的映射区域为整个窗口（包括标题栏、状态栏、窗口边框等）。原点（0，0）在整个窗口的左上角。》
注意：
1）视图窗口没有非客户区域.
2）视图窗口覆盖在框架窗口之上。
3）在《》中的内容，是我根据测试所理解的。翻译原文中映射区域是整个显示屏幕，原点（0，0）在整个屏幕的左上角。这显然是不对的。

5，在创建了一个CDC对象后，一定要注意在完成任务后将其删除。(如果用CClientDC 或 CWindowDC来在堆栈中构造一个DC对象，则不需要我们显式的删除它，CClientDC或CWindowDC对象会在它的生命周期结束的时候自动调用析构函数来完成删除工作）
例如：
CDC *pDC=GetDC();
...
RealeaseDC(pDC);
说明：
CDC* GetDC( );//CWnd::GetDC 获得与当前窗口相关联的CDC对象指针（映射窗口客户区域）
int ReleaseDC( CDC* pDC );//CWnd::ReleaseDC 释放与当前窗口相关联的设备环境

注意：
在MFC程序中，千万不能自己添加代码删除作为参数以指针形式传递给OnDraw(CDC* pDC)函数的CDC对象，应用程序会自动控制它的删除。

6，当利用CDC对象绘图的时候，所绘制的图形都要依赖于设备环境的状态：如画笔、画刷、字体等GDI绘图对象 和 当前映射模式的选择等。
可以使用CDC成员函数了设置所需要的饿设备环境状态。如：SelectObject()函数可将GDI对象随时选入设备环境中。

7，CPaintDC类：当需要重写OnPaint函数的时候，就需要使用CPaintDC类。默认的OnPaint函数会使用已经设置好的设备环境来调用OnDraw函数
注意：CPaintDC类的构造函数和析构函数所完成的工作都是针对显示用的。
例：
void CMyView::OnPaint()
{
CPaintDC dc(this);
OnPrepareDC(&dc);
dc.TextOut(0,0,"for the display,not the printer");
OnDraw(&dc);
}
说明：
1）CPaintDC( CWnd* pWnd );
//CPaintDC::CPaintDC Constructs a CPaintDC object, prepares the application window for painting, and stores the PAINTSTRUCT structure in the m_ps member variable.
2）CPaintDC类的构造函数自动调用BeginPaint,而它的析构函数会自动调用EndPaint.
3）CDC* BeginPaint( LPPAINTSTRUCT lpPaint );
//CWnd::BeginPaint Prepares CWnd for painting and fills a PAINTSTRUCT data structure with information about the painting.
void EndPaint( LPPAINTSTRUCT lpPaint );
//CWnd::EndPaint Marks the end of painting in the given window. The EndPaint member function is required for each call to the BeginPaint member function, but only after painting is complete.
问题：
1）在View类中一旦定义了OnPaint()函数，则WM_PAINT消息由OnPaint函数来响应。OnDraw函数不再被调用。原因？

8，GDI对象：
Class   Windows handle type

CPen   HPEN
CBrush   HBRUSH
CFont   HFONT
CBitmap  HBITMAP
CPalette  HPALETTE
CRgn   HRGN
说明：
Each graphic-object class in the class library has a constructor that allows you to create graphic objects of that class, which you must then initialize with the appropriate create function, such as CreatePen.

Each graphic-object class in the class library has a cast operator that will cast an MFC object to the associated Windows handle. The resulting handle is valid until the associated object detaches it. Use the object’s Detach member function to detach the handle.

9，CGdiObject类有一个虚析构函数，在其派生类的析构函数将与C++对象相关联的WINDOWS GDI对象删除掉。如果构造了一个CGdiObject派生类对象，则在退出程序之前，必须将其删除掉。
利用CDC类的SelectObject成员函数把自己的GDI对象选进DC的同时，保存原来的GDI对象，当任务完成后，恢复原来的GDI对象，这样就可以将自己的GDI对象的删除掉。
如：
GDIStyle *poldGdiObject=pDC->SelectObject(&newGdiObject);
...//完成任务
pDC->SelectObject(poldGdiObject);

10,Windows对任何企图删除库存GDI对象的行为都不予理会。可以利用SelectObject函数把库存GDI对象选入，从而删除当前GDI对象。
原因：
This function SelectObject may return a pointer to a temporary object. This temporary object is only valid during the processing of one Windows message.
如：
pDC->SelectObject(&newGdiObject);
...
pDC->SelectStockObject(StockCGdiObject);//如：BLACK_BRUSH

11，对于显示设备环境，在消息处理函数内部所进行GDI选择在函数退出后不再有效，因此在进入其他处理函数的时候，每次都必须重新设置设备环境。
Windows句柄是唯一能够持久存在的GDI标识。可以使用GDI对象指针调用GetSafeHandle函数可以获得它Windows句柄，再利用GDI对象类的FromHandle函数将句柄转化为对应的GDI对象。
如：
CFont *pOldFont=pDC->SelectObject(&newFont);
m_hOldFont=(HFONT)pOldFont->GetSafeHandle();//m_hOldFont为数据成员,保存先前字体对象句柄
...
pDC->SelectObject(CFont::FromHandle(m_hOldFont));//可在其他函数中，恢复m_hOldFont句柄对应的字体对象。
说明：
1）static CFont* PASCAL FromHandle( HFONT hFont );
//CFont::FromHandle Returns a pointer to a CFont object when given an HFONT handle to a Windows GDI font object. If a CFont object is not already attached to the handle, a temporary CFont object is created and attached.
2）CGdiObject::GetSafeHandle();
//Return A HANDLE to the attached Windows GDI object; otherwise NULL if no object is attached.

12，每一种Windows颜色都是 通过8位的红（R）、绿（G）、蓝（B）的值祝贺来表示的。
面向颜色的GDI函数可以接收32位的COLORREF参数。Windows的RGB宏可以将8位的红绿蓝值转化成COLORREF参数。
说明：
1）The COLORREF value is a 32-bit value used to specify an RGB color.
2）16种标准VGA纯色参见 P70页；256显示卡 多增加4种标准色参见 P71页。

13，字体是GDI对象，在使用上和其它的GDI对象完全一样。
CDC::GetTextMetrics 
BOOL GetTextMetrics( LPTEXTMETRIC lpMetrics ) const;//测量字体高度等参数

14,GetDeviceCaps();
//Retrieves a wide range of device-specific information about the display device.

 

/**************************************/
第六章：模式对话框和Windows通用控件

1，对话框也是窗口，它不当可以接受消息，而且还可以被移动和关闭，甚至可以在它的客户区中进行绘图操作。

2，模式对话框在被关闭之前，用户无法在同一应用程序的其它地方进行工作。模式对话框更易于编程。
无模式对话框在它仍保留在屏幕的同时，用户还可以在应用程序的其它窗口进行工作。

3，对话框控件既可以通过CWnd指针来引用，也可以通过资源文件定义的索引值（和#define常量相关联）来引用。对话框控件本身就是一个窗口。控件通过向上级对话框发送消息来响应用户的动作。
利用ClassWizard可以帮助产生CDialog派生类，还可以使对话框类数据成员和对话框控件相联系。

4，在现存在项目中添加模式对话框步骤：
1）用对话框编辑器创建包含各种控件的对话框资源。对话框编辑器会对项目的资源文件更新，使之包含新的对话框资源，并且该项目的resource.h文件也会被更新，以便能够包含新的#define常量。
2）利用ClassWizard创建CDialog派生类，并将它和第一步所创建的资源相连接。
3）利用ClassWizard添加控件消息响应函数，并进行编辑。
4）在其它类中需要使用地方先构造该对话框类对象，再调用DoModal显示模式对话框。
说明：
1）在产生的对话框头文件中包含一个枚举类型常量IDD，用于设置该对话框资源ID。枚举常量IDD的使用减弱了CPP文件对资源ID的依赖。
2）《在其它类中显示模式对话框后，只有当模式对话框退出后，才继续执行该类显示模式对话框代码后的代码。》

5，在组合筐中Data属性页下，添加一条后按CTRL+RETURN来结束（或添加下条item)。（VC6中按？键可以获取相关帮助提示的）。组合框有Simple,Dropdown,Drop List三中风格，可以是Styles中选择。
列表筐中，用户只能用鼠标选择选择一个条目，而且在对话框编辑器中不能输入列表框的初始选择条目。
在静态文本控件中可以内置'&'符号。运行时候，&符号后面的字符下将有一个下划线。用户在按下ALT键后同时按下相应带下划线的字母，则就可以跳转到相应的控件上去。注意同一对话框中跳转字符不能重复。

6，当DoModal被调用后，实际在幕后引起一系列如下的动作：
CDialog::DoModal->CEx06Dialog::OnInitDialog->其它的初始化->CDialog::OnInitDialog->CWnd::UpdateData(FALSE)->CEx06Dialog::DoDataExchange
用户输入数据...
用户单击OK按钮
CEx06Dialog::OnOk->...其它的确认处理...->CDialog::OnOk->CWnd::UpDateData(TURE)->CEx06Dialog::DoDataExchange->CDialog::EndDialog(IDOK)
说明：
1）virtual BOOL OnInitDialog( );
//CDialog::OnInitDialog This member function is called in response to the WM_INITDIALOG message. This message is sent to the dialog box during the Create, CreateIndirect, or DoModal calls, which occur immediately before the dialog box is displayed.
//Override this member function if you need to perform special processing when the dialog box is initialized.

2）BOOL UpdateData( BOOL bSaveAndValidate = TRUE );
//CWnd::UpdateData ：Call this member function to initialize data in a dialog box, or to retrieve and validate dialog data.
//bSaveAndValidate：Flag that indicates whether dialog box is being initialized (FALSE) or data is being retrieved (TRUE).
//By default UpdateData(TRUE) is called in the default CDialog::OnOK handler and UpdateData(FALSE) is called in the default CDialog::OnInitDialog.

3）virtual void DoDataExchange( CDataExchange* pDX );
//CWnd::DoDataExchange  Called by the framework to exchange and validate dialog data.
//Never call this function （DoDataExchange） directly. It is called by the UpdateData member function.
//Call UpdateData to initialize a dialog box’s controls or retrieve data from a dialog box.

4）void EndDialog( int nResult );
//CDialog::EndDialog  makes the dialog box invisible but does not destroy it.
//Call this member function to terminate a modal dialog box. This member function returns nResult as the return value of DoModal（IDOK表示接受对话框数据，IDCANCEL表示取消对话框数据）. You must use the EndDialog function to complete processing whenever a modal dialog box is created.
//注意：If you implement the OK button in a modeless dialog box, you must override the OnOK member function and call DestroyWindow from within it.

5）当DoModal函数返回的时候，对话框窗口不再存在。我们可以在堆栈中创建模式对话框对象，这样就可以保证当程序控制转向到C++对话框对象所在的范围之外时，它及时的删除掉。

7，代码解释：
void CEx06aDialog::DoDataExchange(CDataExchange* pDX)
{
 CDialog::DoDataExchange(pDX);
 //{{AFX_DATA_MAP(CEx06aDialog)
 DDX_Text(pDX, IDC_BIO, m_strBio);//
 DDX_Radio(pDX, IDC_CAT, m_nCat);
 ...
 DDV_MinMaxInt(pDX, m_nSsn, 0, 999999999);
 //}}AFX_DATA_MAP
}
说明：
1）DoDataExchange、DDX_（交换）、DDV_（确认）函数都具有双向性。如果调用UpdateData(FALSE)（参数为FALSE），则这些数据就会将与控件相关联（值关联）的数据成员的值传递给对话框中的控件；相反，如果UpDateData(TURE)（参数是TURE），则这些函数会将数据从对话框控件中传递给与之相关联（值关联）的数据成员。
2）这里DDX_Text函数被重载，具体参阅MSDN。The DDX_Text function manages the transfer of int, UINT, long, DWORD, CString, float, or double data between an edit control in a dialog box, form view, or control view and a CString data member of the dialog box, form view, or control view object.
其它DDX_函数参阅MSDN。

8,Enter键触发OnOk函数调用：
当用户按下ENTER键后，OS会自动去查找输入焦点落在哪个按钮上，获得焦点的按钮四周将被点线矩形框包围。如果所有的按钮都没获得输入焦点，则OS会自动去寻找程序或资源所指定的默认按钮（默认按钮边框较粗）。如果对话框没有默认按钮，那么即使对话框中没有OK按钮，OnOk函数也会自动被调用。
由于OnOk函数是虚函数，可以重写OnOk函数，将其函数体置空，变可以使使ENTER键无效。
分离OK按钮：改写OK按钮ID，并除掉其默认按钮（Default Button)的设置。

9,p107至WIN32程序员：强烈建议看看，下为简要笔记。
对话框控件会向他们父对话框发送WM_COMMAND通告消息。大多数窗口程序处理函数都是通过一个嵌套的switch结构了处理这些通告消息的，而MFC则更直接了当地把这些控件通知消息和其它的Windows消息放在同一个层次上处理。

10，Esc键触发OnCancel函数的调用，导致控制从对话框中退出，如果是模式对话框则DoModal的还返回IDCANCEL值。其消除方法同ENTER键。

11，事例代码涉及的一些主要函数及补充说明：
1）CWnd* GetDlgItem( int nID ) const;//可用它来获取对话框上控件指针（返回的时候，强制转换成所需要的控件指针），注意临时性。
   void CWnd::GetDlgItem( int nID, HWND* phWnd ) const;
//Retrieves a pointer to the specified control or child window in a dialog box or other window. The pointer returned is usually cast to the type of control identified by nID.
说明：如果需要包CWnd指针转化成一个控件ID，则可以使用MFC中CWnd类GetDlgCtrlID成员函数。
2）GetScrollPos  Retrieves the current position of a scroll box.
   SetScrollPos  Sets the current position of a scroll box.
   GetScrollRange  Retrieves the current minimum and maximum scroll-bar positions for the given scroll bar.
   SetScrollRange  Sets minimum and maximum position values for the given scroll bar.
3）afx_msg void OnHScroll( UINT nSBCode, UINT nPos, CScrollBar* pScrollBar );//CWnd::OnHScroll 
afx_msg void OnVScroll( UINT nSBCode, UINT nPos, CScrollBar* pScrollBar );//CWnd::OnVScroll 
3）所有的水平滚动条都绑在WM_HSCROLL消息控制函数，所有的竖直滚动条则都绑在一个WM_VSCROLL消息控制函数上。（一般控件都有自己的独立的消息控制函数，但[滚动条控件]有点不同，所以对同一个对话框多个滚动条消息处理的时候，一般都将它们的滚动范围设置一致，方便编程）

/////////////////////////
/////////////////////////
///P109-125页内容笔记待续
12，每个控件在显示之前会向其父对话框发送WM_CTLCOLOR消息，对话框本身也会发送该消息。
《对话框和对话框控件都是窗口，也可以在这些窗口中进行绘图操作。（添加OnPain函数，调用Invalidate/UpdateWindow让窗口重绘）》

13,在运行时加入对话框控件：
一般步骤：
1）在对话框类中添加一个内嵌的控件窗口数据成员。一个内嵌控件C++对象将与相应的对话框对象一起被构造和删除。
2）从View菜单中选择Resource Symbols，为新的控件添加一个ID常量。（也可以在Resource.h中用定义）
3）用ClassWizard映射WM_INITDIALOG消息覆盖（Override）基类 CDialog::OnInitDialog函数。在该函数里调用控件窗口的Create成员函数，并显示新的控件（可以用ShowWindow函数）。Windows回在删除对话框窗口的同时也删除该控件窗口。
4）在派生对话框类里，为新控件手工加入必要的通知消息控制函数。（三步：消息控制函数原型说明，消息映射，消息处理函数）

14，Win32编程经验：父窗口和控件之间是通过Windows消息进行通信的（如MFC中象CListBox::InserString函数），但适用于所有窗口类型的控件类成员函数并不发送消息，而是调用Win32函数。

15，Windows通用控件：Win95引进的象[进度指示器]，[滑杆条]，[微调按钮控件]，[列表控件]和[树状控件]。这些控件的代码在Windows的COMCTL32.DLL文件中，其中包括了每个控件的窗口过程函数，及每个控件的注册窗口类的代码，这些注册代码在DLL加载时候被调用。当应用程序初始化对话框时，将使用对话框资源中符号化的类名，来连接到DLL里的窗口过程函数上。这样应用程序就有了控件的窗口，但代码实际上在DLL里。
除了ActiveX控件，大多数控件都是用这种方法实现的。

16，WM_NOTIFY
    idCtrl = (int) wParam; //控件ID
    pnmh = (LPNMHDR) lParam; //指向NMHDR结构指针，该结构由控件管理。
说明：
1）Sent by a common control to its parent window when an event has occurred in the control or the control requires some kind of information.
2）Not all controls will send WM_NOTIFY messages. In particular, the standard Windows controls (edit controls, combo boxes, list boxes, buttons, scroll bars, and static controls) do not send WM_NOTIFY messages.

/////////////////////////
/////////////////////////
///P115-125页内容笔记待续

/*****************************************/
第七章：无模式对话框 和 Windows通用对话框类

1，[无模式对话框]在它处于激活状态下还允许用户在（同一个应用程序中）其它地方工作。
   [通用对话框]则是C++和一组Windows的实用对话框之间的程序设计借口，包括File Open,Page Setup,Color等等，它们都是通过COMDLG32.DLL来实现的。

2，两种发送Windows消息：
CWnd::SendMessage//立刻导致对窗口控制函数的调用
CWnd::PostMessage//将消息放进Windows消息队列。对消息的处理可能被滞后。
具体：
1）LRESULT SendMessage( UINT message, WPARAM wParam = 0, LPARAM lParam = 0 );
//Sends the specified message to this window. The SendMessage member function calls the window procedure directly and does not return until that window procedure has processed the message. This is in contrast to the PostMessage member function, which places the message into the window’s message queue and returns immediately.

2）BOOL PostMessage( UINT message, WPARAM wParam = 0, LPARAM lParam = 0 );
//Places a message in the window’s message queue and then returns without waiting for the corresponding window to process the message. Messages in a message queue are retrieved by calls to the GetMessage or PeekMessage Windows function.

3，对话框实际上应该属于应用程序的主框架窗口，而不属于视图。（对话框默认弹出特性）
（注：还未领悟，先留着。）

4，对话框窗口的创建和取消完全取决与用户的操作，而对话框对象则将直到应用程序被终止时才会被删除。
（除了主框架窗口之外，对于几乎所有的窗口类型，DestroyWindow函数都不会将C++对象删除掉。所以要注意手动添加删除对话框对象代码）

5，Windows 常量WM_USER是用户自定义消息中可以利用的第一个消息ID。
#define WM_USER       0x0400
//The WM_USER constant is used by applications to help define private messages, usually of the form WM_USER+X, where X is an integer value.
说明：
1）CWnd::PostMessage//发送消息。利用wParam , LPARAM可以向响应消息的处理函数传送附加数据信息。
BOOL PostMessage( UINT message, WPARAM wParam = 0, LPARAM lParam = 0 );
2）在WIN32中，用wParam 和LPARAM参数来传递消息数据是最常用的手段（如：将鼠标的X，Y坐标压缩进lParam）。而在MFC库中，消息数据可以更多样的类型来传递（如：可以CPoint对象来传递鼠标信息）。
对于用户自定义消息，只能使用wParam 和LPARAM参数来传递消息附加数据信息。
3）案例说明：
在对话框类中：
#define WM_GOODBYE WM_USER + 5//定义自定义消息
m_pView->PostMessage(WM_GOODBYE, IDOK);//向View类发送WM_GOODBYE消息，附加消息IDOK存放在wParam 中。m_pView指向当前View类对象。
在View 类对象中
afx_msg LRESULT OnGoodbye(WPARAM wParam, LPARAM lParam);
ON_MESSAGE(WM_GOODBYE, OnGoodbye)
LRESULT CEx07aView::OnGoodbye(WPARAM wParam, LPARAM lParam)
{
 return 0L;
}
4）技巧：在对话框类中重载构造函数，参数为CView*指针。再在对话框类中定义一个CView*指针数据成员。这样，如果在View类中通过传入this指针来构造对话框对象的时候，对话框类中CView*指针数据成员可以在带参数为CView*指针重载构造函数里方便获取构造它的View类指针。

6，ClassWizard并不支持用户自定义消息的响应，所以当使用用户自定义消息编程的时候，必须自己编写自定义消息的处理代码。（三步，首先是消息响应函数原型声明，其次消息映射，最后是编写消息响应函数代码。这里要注意：用户自定义消息的消息映射一定要加在BEGIN_MESSAGE_MAP(..)~~END_MESSAGE_MAP()之间，//{{AFX_MSG_MAP(CEx07aView)~~ //}}AFX_MSG_MAP注释宏对之外）

7，对于无模式对话框一定要注意不要调用CDialog::OnOk或者CDialog::OnCancel函数，既在无模式对话框类中必须重载这些虚函数；否则当使用ESC键，回车键或者用鼠标单击OK|CANCEL按钮的时候，会激发对应基类函数的调用，进而导致调用Windows 的EndDialog函数，EndDialog函数只适合于模式对话框。对于无模式对话框，必须调用DestroyWindow函数。
如果需要的话，还可调用Updatedata函数来将数据从对话框控件中传到类数据成员中。

8,Windows通用对话框：
共同特点：都从用户处获得消息，但并不对信息做处理。如：文件对话框只为程序提供路径名，字体对话框只是填充一个描叙字体的结构，并不创建字体。
所有的通用对话框类都从公有基类CCommonDialog派生而来。
COMDLG32中类列表如下：
CColorDialog  允许用户选择或创建颜色
CFileDialog  允许用户打开或者保存一个文件
CFindReplaceDialog 允许用户将一个字符串换成另一个字符串
CPageSetupDialog 允许用户输入页面参数
CFontDialog  允许用户从列出的可用字体中选择一种字体
CPrintDialog  允许用户设置打印机并打印文档

9，注意：在Win32中，不能在标准文件对话框内部动态创建控件。（其它标准对话框中也应该如此吧）

10，嵌套对话框（这些内容熔入EX07B事例中讲解了，不打算重复，强烈建议看看和跟着做做，页码：P135-141。下面只对其中重要的函数做些说明笔记。）
利用MFC，从通用
1）CFileDialog::m_ofn
//m_ofn is a structure of type OPENFILENAME. Use this structure to initialize the appearance of a File Open or File Save As dialog box after it is constructed but before it is displayed with the DoModal member function.
2）CFileDialog::CFileDialog
CFileDialog( BOOL bOpenFileDialog, LPCTSTR lpszDefExt = NULL, LPCTSTR lpszFileName = NULL, DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, LPCTSTR lpszFilter = NULL, CWnd* pParentWnd = NULL );
//bOpenFileDialog
Set to TRUE to construct a File Open dialog box or FALSE to construct a File Save As dialog box.
3）CFileDialog::DoModal
//Call this function to display the Windows common file dialog box and allow the user to browse files and directories and enter a filename.
//If you want to initialize the various file dialog-box options by setting members of the m_ofn structure, you should do this before calling DoModal, but after the dialog object is constructed.
//When the user clicks the dialog box’s OK or Cancel buttons, or selects the Close option from the dialog box’s control menu, control is returned to your application. You can then call other member functions to retrieve the settings or information the user inputs into the dialog box.
4）CFileDialog::GetPathName
//Call this function to retrieve the full path of the file entered in the dialog box. The path of the filename includes the file’s title plus the entire directory path.
5）事例中注意设置自己创建的子对话框上的组筐控件的ID为stc32。这样才保证文件通用对话框嵌入的位置在组筐所在的位置上，否则默认为自己创建的子对话框的同宽度。（stc32应该是与文件通用对话框相关联的，具体是如何关联的哦？）
6）事例中可见到这样的代码（GetParent()->GetDlgItem(IDOK)->SetWindowText("Delete");）来获取文件通用对话框上的控件指针，这里要理解为什么要用GetParent()函数来获得父窗口指针（因为事例中自己所创建的对话框被设置成Child Style。）（Child style,None border,Group box ID=stc32这些设置都是必不可少的，自己可以试着改变这些设置，看看效果印象也就深了）
7）事例中CSpecialFileDialog::OnDelete() 函数中代码（GetParent()->GetDlgItem(0x480)->GetWindowText(m_strFileName);）通过获取文件通用对话框上文件名对应的编辑框的指针调用CWnd::GetWindowText函数来获取编辑框中的文本保存在m_strFileName数据成员中。其中0x480应该是文件通用对话框上文件名对应的编辑框的ID。
8）事例中CSpecialFileDialog::OnDelete() 函数中代码（GetParent()->SendMessage(WM_COMMAND,IDCANCEL);）向文件通用对话框发送IDCANCEL消息，该操作引起OnCancel函数的调用终止当前模式对话框同时使得CFileDialog::DoModal函数返回IDCANCEL值。
MSDN：
CDialog::OnCancel （The default simply terminates a modal dialog box by calling EndDialog and causing DoModal to return IDCANCEL.）
9）SDK函数：FindFirstFile，DeleteFile
//FindFirstFile Searches a directory for a file whose name matches the specified file name on the destination site identified by this object. It examines subdirectory names as well as file names.
//DeleteFile Deletes the given file from the destination site.
10）CFile::Remove
A static function ，deletes the file specified by the path. It will not remove a directory. （注意：用这函数删除的文件是不经过回收站的哦。）

11，在对话框标题栏添加图标：在对话框类OnInitDialog函数中添加如下代码。
 HICON hIcon =AfxGetApp()->LoadIcon(ID_MYICON);//ID_MYICON是用资源编辑器创建的图标ID。
 this->SetIcon(hIcon,TRUE);
 this->SetIcon(hIcon,FALSE);注：这里带上this指针目的是为了强调必须使用目的对话框类对象指针调用SetIcon设置图标。
比如在书EX07B事例中，由于CSpecialFileDialog类设置为子窗口类，而且所关联的资源窗口没有Tittle Bar，要在父窗口文件通用对话框Tittle Bar上添加图标，必须获取父窗口文件通用对话框对象指针来调用SetIcon设置图标。
如在书EX07B事例中：在CSpecialFileDialog::OnInitDialog函数中添加如下代码，可设置文件通用对话框标题图标： 
 HICON hIcon =AfxGetApp()->LoadIcon(ID_MYICON);
 GetParent()->SetIcon(hIcon,TRUE);
 GetParent()->SetIcon(hIcon,FALSE);

/////////////
/////////////

/************************************/
第八章：使用ActiveX控件

1，ActiveX控件是一个直接插入到C++程序中的软件模块，以前常称OLE控件（OCX），是基于MS-COM技术。

2，ActiveX控件与普通Windows控件比较：
相同点：ActiveX控件也可看成是一个子窗口（可以看成这样的）。
如果想在对话框上加入ActiveX控件，则只要在对话框编辑器中，把ActiveX控件放在适当的位置上，并在资源模板中标识该控件。如果要在运行的过程中建立ActiveX控件，则可以调用响应控件类的Create成员函数，而且通常在父窗口的WM_CREATE消息控制函数中调用。
不同点：属性和方法。
ActiveX控件不像普通控件那样发送以WM_打头的通知消息给它的包容器窗口，而是激发事件。事件实际上是由控件调用包容器函数。像普通的控件通知消息一样，事件并没有返回值传给ActiveX控件。事件如lick,KeyDown。但对于客户来说时间与控件的通知消息是一样的。

3，在MFC库中，ActiveX控件就像子窗口一样，但在控件窗口和包容器窗口之间有一层重要代码。实际上，ActiveX控件可能没有窗口。当调用Create函数时，并不是直接建立控件窗口，而是把控件代码载入进来，并激发一个“实地激活”（in-place activation)命令。然后ActiveX控件再建立它自己的窗口，通过MFC的CWnd类指针我们可以访问该窗口。不过客户程序最好不要使用ActiveX控件的hWnd句柄。

4，通常ActiveX控件会保存在扩展名为OCX的动态连接库中。包容器程序回根据Windows注册表利用COM技术在需要的时候装入动态连接库。
说明：
1）暂时可以这样认为，如果使用了ActiveX控件，那么在运行时候要装入该ActiveX控件代码。显然在发布含有ActiveX控件的程序时候，必须要包含相应的OCX文件，而且还得提供一个合适的安装程序。

5，安装ActiveX控件：
1）把找到的ActiveX控件动态连接库拷到硬盘上。
2）在WINDOWS注册表中登记注册。（可使用Regsvr32命令行命令）
3）在使用该控件的项目中安装该控件。（选择Project菜单，再选择Add To Project,再选择Components And Controls，再选择Registered ActiveX Controls，这时列表框列出系统已经注册所有的ActiveX控件，选择需要的控件INSERT即可。）

6，ActiveX控件包容器编程：
1）不管ActiveX控件是作为对话框控件，还是做为“子窗口”，MFC和ClassWizard都支持。
2）ActiveX控件编写者设计了ActiveX控件属性供使用者在设计时访问。所有的ActiveX控件属性（包括设计时属性），在运行时都是可以访问的，不过有些属性可能被设计成只读的。
3）当在项目中插入ActiveX控件时，ClassWizard就会产生相应的CWnd的派生类C++类，来满足对空间的方法和属性进行访问要求。控件的属性和方法都有相应的成员函数，同时生成的类还有一个构造函数可用以动态创建ActiveX控件的事例。
4）当在项目中插入ActiveX控件ClassWizard生成的CWnd的派生类C++类中，可以看到其成员函数的代码中都有对InvokeHelper函数的调用，InvokeHelper函数的第一个参数都和对应的属性或方法在ActiveX控件中的分发(dispatch)ID（标识ActiveX控件的方法或属性的）相对应。通过查看ActiveX控件hlp文件可以发现，ActiveX控件的方法在生存的C++类中都有同名的成员函数与之对应，ActiveX控件的属性都有一组Get和Set函数对其操作，其中ActiveX控件的方法和属性操作与生成的C++类成员函数相关联都是通过InvokeHelper函数的调用来完成的，InvokeHelper函数的第一个参数是由Component Gallery（控件提供者）提供的。因为经过这样的处理，所以我们如果要调用ActiveX控件的方法或对其属性进行取和设置操作，只需调用生成的C++类对应的成员函数便可。
下面对InvokeHelper单独说明：
CWnd::InvokeHelper
void InvokeHelper( DISPID dwDispID, WORD wFlags, VARTYPE vtRet, void* pvRet, const BYTE* pbParamInfo, ... );
说明：
Call this member function to invoke the OLE control method or property specified by dwDispID, in the context specified by wFlags.
其中参数：
dwDispID：
//Identifies the method or property to be invoked. This value is usually supplied by Component Gallery.

wFlags：可以为下面些值，指明调用InvokeHelper的目的。
//[ DISPATCH_METHOD ]   The member is invoked as a method. If a property has the same name, both this and the DISPATCH_PROPERTYGET flag may be set.
[ DISPATCH_PROPERTYGET ] The member is retrieved as a property or data member.
[ DISPATCH_PROPERTYPUT ] The member is changed as a property or data member.
[ DISPATCH_PROPERTYPUTREF ] The member is changed by a reference assignment, rather than a value assignment. This flag is valid only when the property accepts a reference to an object.

vtRet：
//Specifies the type of the return value.
VT_EMPTY  void
VT_I2  short
VT_I4  long
VT_R4  float
VT_R8  double
VT_CY  CY
VT_DATE  DATE
VT_BSTR  BSTR
VT_DISPATCH  LPDISPATCH
VT_ERROR  SCODE
VT_BOOL  BOOL
VT_VARIANT VARIANT
VT_UNKNOWN  LPUNKNOWN

pvRet：
//Address of the variable that will that will receive the property value or return value. It must match the type specified by vtRet.

pbParamInfo：一般都设置为NULL
//Pointer to a null-terminated string of bytes specifying the types of the parameters following pbParamInfo.
specifies the types of the parameters passed to the method or property.
...：
//Variable List of parameters, of types specified in pbParamInfo.

5）AppWizard对ActiveX控件的支持是通过在生成的应用程序类的成员函数InitInstance中插入（AfxEnableControlContainer();），同时在响应项目文件的StdAfx.h文件中插入（#include<afxdisp.h>）（原因可参考书P38一些说明）。
如果项目中不包含这两行，而又要加入ActiveX控件，则只要手工加入上面两行代码即可。

6）可以对话框编辑器来生成对话框的模板中加入一个或多个ActiveX控件，这样我们可以在对话框模板生成的类中添加数据成员或事件控制函数来获取ActiveX控件的属性或对其控制。
注意：（详细见书P159页的[致WIN32程序员]）
实际上，资源模板并不是在对话框编辑器中所看的那样。函数CDialog::DoModal在把对话框模板交给WINDOWS内部的对话框过程之前，要先对模板进行预处理，即：它先会去掉所有的ActiveX控件，有剩下的控件建立对话框窗口，然后再装入ActiveX控件，激活它们并在正确的位置上创建它的窗口。
当模式对话框运行时候，MFC处理所有送给对话框消息时，是不管是有普通控件发送的，还是ActiveX控件发送的。故ActiveX控件虽然不是对话框模板一部分，但用户仍然可以用TAB键在所有的控件间切换。

7）调用UpdateData(FALSE)将会从所有的对话框控件中读取所有属性值。如果只需要得到ActiveX控件属性的话，可以调用ActiveX控件生成的C++类中Get函数（同样设置调用Set函数），这样就提高了效率。

8）事例部分代码对比说明：
代码一：
   CDataExchange dx(this,TRUE);
   DDX_Text(&dx,IDC_DAY,m_sDay);
   DDX_Text(&dx,IDC_MONTH,m_sMonth);
   DDX_Text(&dx,IDC_YEAR,m_sYear);
说明一：
CDataExchange类构造函数：（注，在MFC|SRC|AFXWIN.H中可以看到其构造函数声明，在MFC|SRC|WINCORE.CPP文件中可以看到其构造函数的定义。）
原型：CDataExchange::CDataExchange(CWnd* pDlgWnd, BOOL bSaveAndValidate);
定义：
CDataExchange::CDataExchange(CWnd* pDlgWnd, BOOL bSaveAndValidate)
{
 ASSERT_VALID(pDlgWnd);
 m_bSaveAndValidate = bSaveAndValidate;
 m_pDlgWnd = pDlgWnd;
 m_hWndLastControl = NULL;
}

//其中m_pDlgWnd和m_bSaveAndValidate是CDataExchange数据成员,可以通过这中方式给它们赋值。
m_pDlgWnd：The dialog box or window where the data exchange takes place.
m_bSaveAndValidate Flag for the direction of DDX and DDV. 详见说明二。

说明二：
//CDataExchange does not have a base class.
//The CDataExchange class supports the dialog data exchange (DDX) and dialog data validation (DDV) routines used by the Microsoft Foundation classes. Use this class if you are writing data exchange routines for custom data types or controls, or if you are writing your own data validation routines.
//A CDataExchange object provides the context information needed for DDX and DDV to take place. The flag m_bSaveAndValidate is FALSE when DDX is used to fill the initial values of dialog controls from data members. The flag m_bSaveAndValidate is TRUE when DDX is used to set the current values of dialog controls into data members and when DDV is used to validate the data values. If the DDV validation fails, the DDV procedure will display a message box explaining the input error. The DDV procedure will then call Fail to reset the focus to the offending control and throw an exception to stop the validation process.

代码二：（是为了比较代码一做些说明的）
void CActiveXDialog::DoDataExchange(CDataExchange* pDX)
{
 CDialog::DoDataExchange(pDX);//调用基类的DoDataExchange
 //{{AFX_DATA_MAP(CActiveXDialog)
 DDX_Control(pDX, IDC_CALENDAR1, m_calendar);
 DDX_Text(pDX, IDC_DAY, m_sDay);
 DDX_Text(pDX, IDC_MONTH, m_sMonth);
 DDX_Text(pDX, IDC_YEAR, m_sYear);
 //}}AFX_DATA_MAP
}
说明一：
//DoDataExchange Called by the framework to exchange and validate dialog data.
//DoDataExchange Never call this function directly. It is called by the UpdateData member function. Call UpdateData to initialize a dialog box’s controls or retrieve data from a dialog box.
说明二：
//在MFC|SRC|WINCORE.CPP文件中可以看到UpdateData函数的定义
BOOL CWnd::UpdateData(BOOL bSaveAndValidate)
{ ... 
 CDataExchange dx(this, bSaveAndValidate);//创建了一个CDataExchange对象，与当前窗口相关联
 ...
 DoDataExchange(&dx); //注意：DoDataExchange是个虚函数。子类中如果有重写了，则调用子类的。
 ...
}
说明三：
//在MFC|Include|AFXWIN2.INL文件中可有看到CWnd::DoDataExchange的如下定义（内联）：
// CWnd dialog data support
_AFXWIN_INLINE void CWnd::DoDataExchange(CDataExchange*)
 { } // default does nothing
由此可见代码二中CDialog::DoDataExchange(pDX)调用好象是个‘摆设’，不起做任何事情。框架设置DoDataExchange函数目的是在我们子窗口类（这里是对话筐）中重写它，添加代码完成子窗口类（这里是对话筐）中数据成员与对话筐上控件的交互。
说明四：
如果结合UpdateData和DoDataExchange两函数整体来看，应该体会到这里代码一与代码二实质上是一会事情。代码二只是借助了框架兜了些圈子。

说明四：
摘录MSDN中Dialog Data Exchange一些E文段落对上讨论做个总结：
Dialog Data Exchange

If you use the DDX mechanism, you set the initial values of the dialog object’s member variables, typically in your OnInitDialog handler or the dialog constructor. Immediately before the dialog is displayed, the framework’s DDX mechanism transfers the values of the member variables to the controls in the dialog box, where they appear when the dialog box itself appears in response to DoModal or Create. The default implementation of OnInitDialog in CDialog calls the UpdateData member function of class CWnd to initialize the controls in the dialog box.

The same mechanism transfers values from the controls to the member variables when the user clicks the OK button (or whenever you call the UpdateData member function with the argument TRUE). The dialog data validation mechanism validates any data items for which you specified validation rules.

UpdateData works in both directions, as specified by the BOOL parameter passed to it. To carry out the exchange, UpdateData sets up a CDataExchange object and calls your dialog class’s override of CDialog’s DoDataExchange member function. DoDataExchange takes an argument of type CDataExchange. The CDataExchange object passed to UpdateData represents the context of the exchange, defining such information as the direction of the exchange.

When you (or ClassWizard) override DoDataExchange, you specify a call to one DDX function per data member (control). Each DDX function knows how to exchange data in both directions based on the context supplied by the CDataExchange argument passed to your DoDataExchange by UpdateData.

MFC provides many DDX functions for different kinds of exchange.

If the user cancels a modal dialog box, the OnCancel member function terminates the dialog box and DoModal returns the value IDCANCEL. In that case, no data is exchanged between the dialog box and the dialog object.

9）当输入焦点在某ActiveX控件上时，按下F1键引起OnHelpInfo函数调用，可在OnHelpInfo函数中设置帮助信息。
说明：
ClassWizard不能修改生成的ActiveX控件类，因而必须手工加入消息映射代码。事例代码如下：
//在ActiveX控件类头文件中加入函数原型并声明消息映射表：
 protected:
  afx_msg BOOL OnHelpInfo(HELPINFO* pHelpInfo);
  DECLARE_MESSAGE_MAP()//在ActiveX控件类代码文件中添加消息映射及OnHelpInfo函数定义：
 BEGIN_MESSAGE_MAP(CCalendar,CWnd)
  ON_WM_HELPINFO()
 END_MESSAGE_MAP()
/**
 BOOL CCalendar::OnHelpInfo(HELPINFO *pHelpInfo)
{
 ::WinHelp(GetSafeHwnd(),"C:\WINDOWS\system32\MSCAL.hlp",
    HELP_FINDER,0);
 return FALSE;
}

/////////////////
//////////////
///////////

7，在运行时创建ActiveX控件：
1）在项目中插入ActiveX控件。ClassWizard会生存相应的ActiveX控件类的文件。
2）在使用ActiveX控件的对话框或窗口类中添加ActiveX控件类数据成员。
3）重写CDialog::OnInitDialog（或其它窗口中响应WM_CREAT消息），在新的函数中调用ActiveX控件类Create函数。
4）在父窗口类中，手工添加必要的与新控件有关的事件消息处理函数及原型，和相应的消息映射。

/////////
8，更多的ActiveX控件编程参见P160-167页（ActiveX控件在HTML文件中使用 和 在运行时创建ActiveX控件）。