坐在框架上的程序员_写框架的程序员

那天我在网上看见，说用C++写程序太复杂了。

翻开C++的教程，我们会发现C++的语法很简单，结构很清晰，它怎么会复杂呢？后来我才发现，他不是说C++语言本身，而是说用C++写出来的程序。

举个很简单的例子，通过MFC开发应用程序，在程序的入口函数为CWinApp::InitInstance()；这个函数由AppWizard自动为你生成；

BOOL  TheApp::InitInstance(){

        AfxOleInit();//如果你的应用程序中要使用到OLE对象，必须调用它进行初始化
        AfxRichEditInit();//如果你要在应用程序中使用超文本框，必须调用它进行初始化
        AfxSocketInit();//如果你要使用Socket功能，必须调用它进行初始化

}

而通过vb.net在.net 框架上开发应用程序时，你不需要考虑程序的入口的初始化问题，在使用上述对应的功能时，也不需要考虑初始化问题，开发人员只需要将精力集中在业务处理上。

通过以上两种程序的对比，我们就可以很容易发现，当你通过C++写程序时，你除了注意程序在处理业务上的逻辑外，你还必须注意程序本身处理的细节问题，或者是你必须注意程序本身的逻辑细节问题。

例如，在vb.net中，我们通过.net框架开发，当我们需要在窗体上用一个Rich Edit Control的时候，我们想到的是直接从工具箱中拖一个到窗体上就完事了，之所以要用到Rich Edit Control，是因为业务处理逻辑的需要。而在通过MFC开发时，我们同样处于业务处理逻辑的需要，将Rich Edit Control控件拖放到窗体上，但是我们还要考虑到程序本身执行的逻辑，在InitInstance()方法中调用AfxRichEditInit()方法来初始化。

这两种开发很可观，其实也没有什么好说的，我们换一个角度，从工程管理的角度上来说，用vb.net开发肯定是优于用C++的。首先vb.net的开发效率比C++明显要高，还有其它优势，比如：垃圾自动回收，类型安全等等，网上多的去了。对于这样的事实，我也没有什么好说的，都是事实嘛。

我想说的是，现在有一部分程序员，他们对控件功能的依赖程度实在是太大了，一打开开发工具，就看它里面有什么控件，遇到了问题，想到的第一件事情就是这个开发工具里是否有这种功能的控件，如果没有，就到网上去找，如果找不到，就认为这种功能不能实现。是的，在控件上开发是让开发变得很简单，各个开发工具的制造商也发现了这点，在自己新一代的开发工具中，加入和很多新的，功能很强大的控件，更有甚者，提供了解决方案的模板，让开发者稍微用鼠标设置一下，就可以完成一个IT解决方案。

当这部分在框架上开发多年的程序员再来看C++写出来的程序的时候，当然它们会觉得很复杂。其实程序本身就是那个样子，只是长久以来，程序本身的真正面目被各种强大的框架遮住了。很多本身应该由程序员来完成的代码、由程序员来完成的处理逻辑被框架自动完成。

我在这里并不是说要放弃使用框架，什么代码都自己来写，这是不科学的。我只是想提醒各位写程序的同行，当你通过框架写完一段程序的时候，不要忘记这段程序后面还有一段程序。