MVC不简单!

这两天在为一重构的最后一步而头痛，因为有三个函数，总体上的算法是基本上一样，只是因为在取数据的方式上有一点点的不同，如何将这三个函数重复的部分合并在一起，有点让我心烦，因为可以选用的办法有两种，一个是使用Template Method模式，或者是strategy模式。本来这两种方法都可以解决这个问题，不过选择上是一点点让我为难：

如果用template method的话，就需要从中提取出一个更抽象的基类，但这三个函数的所有者之间的关系却看不出来拥有这样的一个共同基类的概念，如果硬抽出来会比较怪怪的；那这样就简单了，用strategy嘛，不过问题是抽出一个strategy却好象strategy类的接口的语义性不强，或者说是接口的内聚性也不太好，看上去总是有点点怪怪的。

或者别的重构方法会是更好的办法？噢，也许，不过我不知道，也没有想出来。

只好将这个方案拿出来与办公室的大师讨论，呵呵，大师果然是大师。看了一下我的代码与整体设计之后，明确的告诉我，的确这两种重构方法都对我的这个实现来说都不是好的方法。我听了之后感到有点释然也有点懊恼，那怎么办？

大师一语道破天机：其实这个问题是出在架构上，现在从底层来改，怎样都弥补不了架构上的缺陷。唉，汗啊。真正根本的解决之道，就是从架构上重构，怎样重构？用MVC模式，再重新对程序分析设计一次。

嗯？MVC，晕，MVC我都已经明白很多年了，不至于吧。心中还隐隐有些不太信服。姑且听听吧。一听之下，才发现自己当年的理解是何等的肤浅，唉。

MVC的原理这个是简单的，思路也是明确的。但是MVC真正最难的地方就是怎样来划分M与V，从而将需要的功能分派在M与V中，对于C则更简单一些，可以将联接M与V的并且都不属于M与V的部分放在C中，总体上来说，M的可重用性会更高一些，而V的可重用性会低一些，而C则更低一些。

现在的问题是，究竟什么样的东东是属于M，而什么样的才是属于V的呢？嗯，这里的原则其实并不麻烦的，只要是可能会呈现成两种方式的东东，都应该是M的。M是应该永远不知道自己会呈现成什么样子的。而与呈现密切相关的就自然是属于V的，并且要将V最好抽象的比较薄，这样才比较好，V最好是不需要知道自己要显示的数据是什么意义，它只需要将内容给它，它就直接拿来显示就可以了。

但是问题是，对于象word或者报表之类的系统，它的显示逻辑也是复杂的一部分，这就注定V的那一层会显得比M重得多。那怎么办？噢，其实V本身也应该是可以分层的，V自身也是可以再分解成V与M的嘛，这样来说其实GDI API这一层本身就应该是最外的一层V了，而呈现的一些内在逻辑则可以考虑成M了。

嗯，受益良多啊，虽然我对这么薄的M与这么重的V还心存疑虑，但总体上却感觉有很多收获，而且看到了对自己在MVC理解上的盲点。

为了去除心头上的疑虑，我又再读了一次GOF的DP的等二章，那一章也正好是讲到了一个类似Word的系统的设计方案。一读之下，才发现，果不其然，原来GOF的设计也是这样的啊，唉!看来我是天生有一些驽钝啊。

呵呵，今天先说到这，下次再将更详细的感受写出来吧。且听下回分解!