WPF 引起的软件架构思考

 

一、引言

一看，又4个月没发文章了，这4个月除去春节奔波，基本上一直在加班，在中国做程序员总是与外国同行不一样，起跑线上输得很厉害。其实按照《人件》统计，程序员一天如果能顺流超过3个小时，基本上就可以秒杀绝大多数问题了。问题是在我们现行的工作环境下，经常是一天连一分钟顺流都进入不了，必须是各种打扰，各种打断，看似提升了效率，事实上是降低了效率。而且，绝大多数时间，我们可能花在了调试错误上，而非本身的逻辑问题上。这样，一天比老外多工作几个小时——以完成同样的目的——就是很正常的了。

呵呵，说着要说WPF的，怎么发了一堆牢骚，其实论环境，比起很多人来，我可能已经是蒙受了很多恩惠了。每天至少有一些充电的时间和机会，不说废话了，接下来还是进入正题吧。

二、正题

WPF（Windows Presentation Foundation）是微软2006年提出的，虽然看似比Forms简单，但其实发展潜力很大。

MFC对我是噩梦，System.Windows.Forms没有好多少（当然，有朋友说我连Forms的1%都没发挥出来）。这两个库一个比较大的问题是在于表现与内容是分开的。Forms已经添加了数据绑定，这个还不错，但是也没有能从根本上解决问题，很多时候我们把精力花在了处理数据的表现上。这其实引入了很多不确定的因素，并导致了潜在的错误增加。

WPF我一开始是很排斥的，当看到它的数据绑定之后，感觉非常好用——在编写XAML的时候，只需要很简单的语法，就可以把一个控件真正的变成一个数据本身。数据变化则控件的表现形态变化，而且这一切是以比Forms和MFC更好的方式来做的——调用约定。实现一个接口，就可以让控件知道它如何去反映一个数据本身。这样，对于“从数据到表现”，就是若干约定，人们信守了约定，就可以把数据真正映射成为表现，而更关键的是这些约定的重用就成为了可能。

我们看《设计模式》，一个最大的感觉就是，这不是具体的编码方法，而是一种约定的方法。一定要有这样几个组成部分，它们之间如何通信，如何交互，但是每个组成部分本身的自由自在，是没有人去限制的。

我感觉，程序是用来描述“客观实在”的，也就是说程序是用来描述其所面对的一个体系的特性的。这些特性包括，体系包含着哪些概念？概念与概念之间的相互关系如何？

一开始，我们认为一个体系有若干流程，数据是在流动的，控制是在流动的——因此有了基于过程的程序设计，这是一切的根本。

后来，我们发现，体系内部的概念往往本身就代表了一系列的数据和控制集合——因此就有了基于对象的程序设计。

后来，我们发现，为了增加扩展性，体系内部可以有一些小概念来描述一个个独立个体，然后由这些独立个体多态组合为一个真正的行为个体——因此有了面向对象的程序设计。

最后，我们发现对象爆炸了，数据也会变化，控制也会变化，世界上的一切都在变化，还有什么是不变化的呢？契约。——于是就有了WPF。

当然最后一句是开玩笑的。契约的意思就是我不管你怎么做，我只要你提供给我什么结果，或者我告诉你我要给你什么通知——约定最好的实现方式就是接口，而不是实体类，因为类带有了数据，这就难免影响实现者对于一个问题的判断。

WPF和2006年出现的其他一些技术一样，就是对这个问题的一个回答。数据——其实就是概念——你爱变不变，爱怎么变怎么变，对于WPF而言，需要的就是你去实现一个接口，就可以把你的概念容纳到我的系统中来。

在工作中，我发现很多人很可能忽视了UI系统的重要性——UI系统其实就是一个最简化的游戏系统，设计UI系统的方案中间包括了你游戏系统中可能面对的基本问题和基本思路。很多人喜欢从一些具体的细枝末节去考虑这个问题，比如谁的UI实现了订阅者模式，谁的UI实现了数据驱动，谁的UI实现了脚本驱动，谁的UI酷，炫。但其实更核心的是来参考这个UI系统的构成——基于白盒理念（继承）的设计还是基于黑盒理念（订阅者）的设计，两者如何融合？是否区分了设计时（Designer）和运行时。等等之类的问题。

WPF在这个方面可能能带来一些新的想法和思路——不同于我们浪费唇舌于MFC的继承机制和Forms的继承+订阅机制谁更优秀的新的思路：

基于约定而设计一个体系的思路，基于契约而设计一个体系的思路，基于组件和模块而设计一个体系的思路。

因为体系，之所以要提出体系，就是为了能容纳更多的人进入到体系之中。这就好比原始的工厂和流水线工厂的区别。原始的工厂体系下，一个人需要处理一个零件从头到尾的全过程。而流水线下面，一个人只需要完成确定模块的确定任务。如果说流水线极大地提升了人类的劳动生产率，那么我相信一套优秀的体系设计同样能带来这样的好处——如果它可以让每个模块的参与者不知道其它模块的存在，那么这样的理想境界至少是降低了大量的学习和调试的成本。无数次的实践证明，模块内部的错误很好抓，跨模块的错误将是致命的。

参与项目的人越来越多，牛人也越来越多，现在的游戏开发已经不再是那个连找人都困难的时代了。接下来的问题，难道还是谁能做个好效果，谁能做个酷编辑器的问题么？在目前所从事的这个项目中，我感受到了一次深刻的碰撞，我看到一个构架堪称完美的服务器，在需求的冲击面前屹立不倒，也看到过一个崩溃的UI，对新需求近乎没有耐受能力。我认为，好的体系的设计并非只是空中楼阁，它不过就是程序设计到了一定阶段，接近于社会化大生产之前，必然而然所面对的客观规律。如果认识到了这个规律，并且在实际的生产生活中应用了这些规律，至少能得到一些必要的收益。

你可以不知道，并非你无权知道，而是因为你有权不知道。