编程语言的组成
编程语言做为一种语言自然和英语这些自然语言有类似的地方.学英语时我们知道要先记26个字母,然后单词及其发音,接下来就是词组,句子.反正简单的说就是记单词,熟悉词法,句法.接下来就是应用了,听说读写.而使用相同语言的人大脑里都有个翻译器,可以把自己的想法翻译成语言然后用说或写表达出来,而听和读则把接收来的语言翻译成自己大脑能理解的思想.
那编程语言首先也是像英语一样会制定一些单词,然后词法,句法.像int ,char这样的类型关键字,或其他一些关键字就是单词.但这样的语言机器不认识的.所以就要个编译器来翻译成电脑能认识的01串.编译器就像大脑中的翻译器了.所以简单的说起来,一些语法规则加一个编译器就可以标志一门新的编程语言产生了.但语言内置的的都是些非常基本的操作,你要实现个啥复杂点的功能得写很多很多代码,于是有些人就先把很多常用的操作写好代码放那,你以后只管去调用.造好了很多轮子等着你用就行.这就是开发一些库(library)让你调用.在面向对象的语言中一般就叫类库,就是一堆堆的类嘛.如果类库足够强大,我们也可以叫作框架.反正我们可以简单的把框架理解为一些功能强大并且联系紧密的类库.
MFC和QT是C++中常见的GUI框架
WinForm和WPF是C#中常用的框架
不过我们一般很少叫WinForm框架,可能直接叫图形控件类库更多点.反正只是个称呼罢了,爱咋叫就咋叫.另外WinForm与WPF(即Windows Form与Windows Presentation Foundation,用于windows的上的桌面应用开发)都只是提供了一堆GUI类库,而MFC与QT除了一堆GUI类库外还提供了其他很多类.功能更强大.
GUI的重要性
GUI即graphical user interface(图形用户界面).可能很多人觉得整那些页面是个没啥技术含量的活.但实际上很多时候用户可不知道你后台代码咋写,也不管你咋写.他们看到的只有UI,觉得页面看着舒服,用起来性能不是太差,用个专业点的词说就是用户体验很好,那这就是个好软件产品.像苹果公司的产品这么受欢迎其中很重要的一个原因就是UI做的漂亮,让人觉得很酷.我们开发一个软件产品时,如果站在开发者的角度(站其他角度可能不一样)一个软件无非就是保存数据,处理数据,数据间一些逻辑操作,然后通过一个好友的UI界面与用户交互(当然有少数后台软件是不需要UI界面的).
我们知道各种设计模式是满天飞,五花八门,但知名度最高的是MVC模式(model , view,controller).就很好的体现了这一点,model + controller是数据处理那一块,而view就是UI界面.实际上QT,MFC,WinForm,WPF都相当于简化的MVC模式,由三层变成两层.model +controller没做区分,弄成一层了.而view这一层则是单独弄出来,UI与与数据的逻辑处理代码的分离使得条理清晰,便于理解与维护.而且更重要的是很多UI控件都是做好了的,你直接拖来用不行.
另外你可能可能听说过STL(standard template library),标准模板库相当于把数据结构及对数据的操作(算法)这些常用的东东都做好给你调用,相当于把数据结构和算法那些思想实现成通用的代码供你调用.
为啥把这四个框架放一起来说呢,因为四者之前有类似的地方.相同语言之间的框架有相似那是毫无疑问,但实际上不同语言之间的类库也有类似的地方了
C++中的MFC和C#中的WinForm有点类似
而C++中的QT与C#中的WPF又有点类似
MFC与WinForm
前面讲了这四个框架都是简化的两层的MVC模式.MFC中数据的逻辑处理自然是放后缀为h,cpp的这些文件中.而页面相关的那一堆东东放资源文件rc后缀的文件中.一般是一个project对应一个rc文件,但也可以多个project共用一个rc文件.当然在VS这开发环境中不会因为所有信息放rc文件中就所有页面控件堆一起了.在Resource View可以看到一个个分开的Dialog,每个Dialog就是一个页面,里面装着button等一些控件.当然资源文件还可以放其他资源的比如String Table,Bitmap之类的.如果你查看rc文件里的code,都是一堆begin 和end包起来的乱七八糟的东东.内容自然是控件的一些属性.code语法跟c++标准语法没半毛钱关系.也不知道是按啥语法组织的.
分开了UI层,如果那些处理数据逻辑的代码要与UI交互就靠资源ID去关联.比如很多类可以共用一个Dialog页面,当然了很多时候我们一般是一个class对应一个dialog的.MFC中UI页面与后台代码交互起来很不方便.比如要让某个控件(button,combobox之类的)与某个变量对应起来还得在DoDataExchange那函数里面写点代码关联起来.如果要点button要对应啥操作还得通过begin_message_map这样的宏来关联下.把某个控件送出的消息与一个函数对应起来的.当然了因为所有控件都继承自CWnd这类,所以也可以通过这类的一些函数去直接操作控件,比如GetDlgItem这样的函数,传资源ID做参数就行.
WinForm中也遗留了MFC一些思想,比如还有类似资源文件的东东,像Resources.resx文件,里面一般是放图片信息,然后Setting.settings就类似MFC里的string table.只不过这些功能在C#中用的很少.那些页面控件也不再是放资源文件中.WinForm中一切皆使用面向对象,数据逻辑处理代码与UI代码都是在同一个类中,只不过C#有分部类的概念,就是说同一个类的代码可以分开在几个文件中.假如有窗口类FormArwen,则数据逻辑代码放在FormArwen.cs文件中,UI代码放FormArwen.Designer.cs文件中.只不过这两个文件中类的定义都要写在partial class FormArwen 其中关键字partial是C#中独有的关键字,用来表示分部类,一个类可以在多个文件中定义.这里的UI代码也完全是标准的C#代码,不像MFC资源文件缺乏可读性.而且你完全可以把UI代码拷贝到数据逻辑代码中,放一起也完全没问题.
窗口中每一个控件都有一个name,相当于mfc中的资源ID吧,然后你在代码中调用控件时直接用这个名字就行,就相当于一个变量名字.所以代码与UI交互起来非常方便,另外MFC中的消息机制在这里被封装成了事件(event),你选中任意一个控件然后在它的propterties 的event页面中选择任意一个事件点击下就会自动生成一个类,你往类中直接写要处理的事件代码就行.这实际上就是把win32 API中复杂的消息机制简化为一个event,用户用起来很方便,也不用管背后的复杂逻辑.MFC虽然对消息机制做了些封装,但封装的还不够好.
所以WinForm相对MFC而言,UI代码与数据逻辑处理代码交互更简单,更条理清晰,易于理解.背后一些复杂的细节都封装了不用用户管了.而且UI控件是功能更强大,看起来更漂亮啊.
QT与WPF
同为C++的GUI框架,QT与MFC不那么相似,那种逻辑反而更接近C#的wpf框架一点.首先不是所有UI相关代码都像MFC一样整到一个rc文件,而是一个UI页面有对应一个后缀为ui的的xml文件.而数据逻辑处理代码是放h,cpp文件中.而且这三个谁的名字都相同. 而如果要与控件交互也跟wpf一样方便,每个控件有个objectName,相当于MFC的资源ID号,然后调用控件时直接用这个名字就行,当然前面要加个指向自身所在类的指针.比如有类Arwen,有button名为btn,则一般是先Arwen* ui; 然后ui->btn就行.实际上跟wpf中用this.btn一样,只不过wpf中this前缀是可以省略的. 另外QT里面也没有MFC中的消息处理概念,而是封装成一个叫signal / slot的机制.这跟C#中的WinForm事件(event)非常类似,例如你右击QT中的一个按钮,然后右击go to slot选择一种signal,就相当于C#里面的各种类型的事件,当然signal的各类要少点.然后slot就是事件对应的处理函数.
WPF也是一个UI页面对应一个文件,后缀为xaml的文件,xaml全称是eXtensible Application Markup Language我们可以把它看成一种特殊的xml文件.而QT里面的ui文件就是标准的xml文件了啊.然后其他UI无关的代码就放xaml.cs文件中.
应该说从符合我们思维习惯的角度来说WinForm是最容易理解的,UI页面对应的代码完全是标准C#代码. 而MFC页面对应的rc文件,QT页面对应的xml文件,WPF页面对应的xaml文件都不是标准的C++或C#代码.不太符合我们的思维习惯.
知乎大牛的介绍
WTL都算不上什么Framework,就是利用泛型特性对Win API做了层封装,设计思路也没摆脱MFC的影响,实际上用泛型做UI Framework也只能算是一次行为艺术,这个思路下继续发展就会变得没法用了,比如 代码过于复杂,编译太慢,出错不好调试等问题难以解决。
而且封装得也不完全,还是随处可见 HWND HDC之类的东西。
用途主要是写一些很小的程序,或者作为其他UI框架的后端实现部分,比如我写过一个小框架用来做安装卸载程序,非常小,其中创建管理窗口部分是用WTL的。MFC是更高级点的Win API封装,比WTL封装彻底,很难见到HWND HDC了,也提供了不少实用工具类,比如高级控件,泛型容器,IO访问,网络协议等。除此之外,还提供了一些基本框架,比如 Document/View,这就是个MVC的简化版本,只有MV,但是对于数据的管理,消息的传递等又没有什么约束,导致Doc/View被用得乱七八糟。尤其是对事件处理的模型,消息映射是功能简陋,而且容易出错的方式,唯一优点是性能好。 从VC++ 1.X就有MFC了,那时整个UI界的设计思想都比较落后(除了Apple),MFC又背负了沉重的兼容性包袱,比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译,导致MFC后期没有什么发展,就是沿着老的思路完善了些细节,添加了些组件,但是根本性的设计问题没有改进。GTK,这个吃了语言的亏,用C写面向对象实在是痛苦,虽然在思想上比MFC要先进了些,但是写出来的代码比MFC要罗嗦很多了。相比MFC,多了Layout的概念,事件处理上有了Signal/slot,虽然用起来很麻烦。wxWidgets,这个基本就是个跨平台的MFC,对各个平台的差异做了抽象,实际上后端大多还是用平台原生的API实现,好多控件都是直接用系统原生的。有wxWidgets for GTK+的版本,后端就是GTK+,wxWidgets就是一层壳。这也是wxWidgets的优点,它编译出来的程序发行包比较小,性能也不错。以上这些就是上世纪90年代的UI Framework技术水平了,至今它们也依然没有太多进步。
下面来谈谈21世纪的技术。
Qt,虽然它也是上世纪90年代出现的,但是它在21世纪有了长足的进步。应该说它的起点就比较高,一开始就定位跨平台,而且不满足于简单封装系统API,而是要自己创造出一套完整的API和框架,甚至要代替系统API,所以不仅仅是做UI,而是涉及到了APP开发所用到的所有东西,包括网络,数据库,多媒体,脚本引擎等。signal/slot是Qt发明的,这是事件通知模型里C++语言的最佳实现了,甚至我都觉得这该写进C++标准,估计C++委员会的老顽固们是从不写GUI的。
早期的QT也是没有DirectUI的概念的,每一个QWidget都对应一个原生窗口,从Qt4.4开始,只有顶层QWidget才是原生窗口,而Child Widget是Alien Widget,只是个抽象的图层不对应原生窗口,这就实现了DirectUI的概念,很多图形效果也就变得可能了,比如窗口层叠透明效果。
在4.8后实现了QPA(Qt Platform Abstraction),这就使移植Qt变得很容易,目前Qt是支持平台最多的框架没有之一。
由于早期授权的问题,Qt对于开源社区不是很友好,导致推广不太顺利,直到它改成了LGPL方式,如果Qt能早点想开了,恐怕就没有wxWidgets的生存空间了。
Qt的缺点也是有的,就是太大,不过可以自己剪裁,我可以把QT库剪裁到发行包压缩后2.5MB。
WPF,微软在Win Form的思路上走到死胡同后,终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的,绝对不能是代码写出来的,所以有了XAML这个强大的定义工具,不但可以定义UI布局,还包括图形动画效果,消息响应方式等。配合C#这种优秀的语言,更是如虎添翼。但是问题也很明显,就是过于庞大,不仅开发时要用到庞大的IDE和设计工具,发行的安装包也十分巨大,所以目前还是很少有人拿他写通用软件客户端的,大多是做企业项目时写专用客户端。
大概4-5年前吧疼讯曾经用WPF写了个QQ,但是只实现了基本功能就已经比C++客户端大好多了,而且运行缓慢,主要是太吃内存,而且那时WPF的优化还不充分。
最后我想补充下真正的UI库之王,cocoa。
Apple的成功有很多原因,其中之一就是cocoa,cocoa理念十分先进,而且出来得早,我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。
定义式的UI,用xib就可以定义UI的绝大部分细节,而且提供所见即所得的可视化设计工具。
严格的MVC,而且定义非常清晰,分工明确。
signal/slot,虽然不叫这个名字,但思想就是,而且真的是拖动鼠标就能connect。
提供了ARC,闭包和反射,给UI开发带来巨大的便利性,当然这得益于Objective-C这个语言。
再补充下 Borland的OWL和VCL。
我是从Borland C++3.0和Delphi 1.0开始用的,那时的Borland看来很有前途的,可惜后来一系列决策失误导致现在这个公司几乎消失了,同学们不要再往这个坑里跳了。
OWL曾经和MFC是竞争对手,设计思想也差不多,个人感觉OWL的API设计更优雅一点,但是在市场上OWL被MFC彻底击败。
Delphi是神作,它在RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构。Delphi的特点就是简单、开发快,单纯就写个基本可用的应用来说,可能至今都没有比他更快的,但是缺点就是丑,基本大多数Delphi应用都是一大堆控件堆积在一起,很不美观,另外由于Pascal语言的限制无法和现有大量的C/C++代码融合。虽然后来有C++ Builder,但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差,导致后来开源项目都不太愿意兼容这个编译器了。
VCL准确地说不是UI库,而是一套组件接口规范,类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。
UI库是个很大的话题,够写好几本书来探讨的,我这里就是随便写点自己的感受。
单纯讨论每个库的优劣是没有意义的,而是要放到具体的应用场景里来看,每个库都有自己擅长的场景。
如果仅在Windows下,追求程序小巧,用WTL,不足的地方自己实现去吧,但是视觉效果就呵呵了。
如果可以大一点,还要好看点,那就Qt。
如果完全不在乎大小,只要视觉效果华丽,就用WPF,如果把开发工具价格也考虑进来,那么土豪才会选WPF呢。
MFC就是个鸡肋了,除非你现有的工程师不会用别的,或者有历史遗留代码要保持兼容。
如果要求跨平台,那么就用Qt,wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。
如果是iOS Android,那么最好用原生UI库,除非你写游戏。