代码“中间地带”的封装与复用

先提出一个词：中间地带。

作为一个框架提供商，微软公司为我们提供了最基础最常用的类和方法，在实际工作中，我们需要去继承去组合这些类与方法，形成我们的解决方案。
那么，存在一个问题，为什么微软公司不为我们提供一个无所不包无所不能点一下鼠标就会出现的万能代码库呢？
因为……不现实。
有一个类Root，A需要这个类具备的功能列表假设为F(A)，B需要这个类具备的功能列表为F(B)，……，Z需要这个类具备的功能列表为F(Z)。
一个万能的解决方案是为这个控件实现F(God)=F(A)UF(B)UF(C)……UF(Z)这么多功能。而实际上，框架提供给我们的只有F(Root)=F(A)∩F(B) ∩F(C)……∩F(Z)这么少的功能。
对A来说，在F(Root)和F(A)之间，就存在一大片中间地带：F(Root)-F(A)，如下图中的阴影部分。

这个中间地带（阴影部分），就是我们的舞台。

本文重点谈谈中间地带的复用。

一、扩展方法

中间地带中的代码复用有很多种方法。

最直观的是继承。继承一个类，为它加上我们希望而微软又没有提供给我们的行为。再回到中间地带那张图，我们可以得出这个结论：

所有的类都是不完备的，因为F(God)!=F(Root)

不过，对于A来说，我们不需要考虑F(God)，只需要考虑F(A)，为这个类补上F（A）-F（Root）之间的部分就可以了。

一个Bitmap类，我们希望这个类中有这样一个方法:

void DrawPoint(Color color, int x, int y)

 这个方法不能抛出异常（不然就太难用了），当x,y超越了索引就啥都不画。

使用继承的话，我们就要产生一个新类：XXXBitmap。怎么看怎么别扭，因为这个方法理应是 Bitmap 应该具备的行为。

现在，我们有了扩展方法。一切变得自然：

这个例子比较简单，下面，来一个略微复杂的例子。

在Winform程序中，一个窗体或一个独立的线程T调用另一个窗体F中的方法Foo()，这个Foo()会牵扯到UI操作。这里就需要做很多事情。

首先，需要判断F是否已经关闭(F.IsHandleCreated == true)
然后，如果F未关闭，则把Foo()方法封装成一个代理WrapperOfFoo，再调用F.Invoke(WrapperOfFoo)，把这个代理塞给F所在线程
最后，当F线程执行Foo()方法时，在Foo()方法的内部还需要再判断一下F是否已经关闭。

非常繁琐，一不小心就会因遗漏而出错。

下面，我们来设计扩展方法，封装上面的调用逻辑。

扩展方法的原型为：
InvokeFunc0(Func0 func0)
InvokeFunc1<T>(Func1<T> func1, T obj)
InvokeFunc2<T0, T1>(Func2<T0, T1> func2, T0 obj0, T1 obj1)

Func0,Func1,Func2是我自定义的几个delegate，因为.Net 2.0下没有Func。

下面是Func0,Func1,Func2的原型：

 public delegate void Func0();
 public delegate void Func1<T>(T obj);
 public delegate void Func2<T0,T1>(T0 obj0,T1 obj1);

设计这个扩展方法需要使用一点点小技巧。

我们用一个类ControlFuncContext来封装Foo()方法的运行时环境：

Code

有了这个类，扩展方法就非常好写了：

Code

扩展方法是一个好东西。下面是俺常干的事情。

（1） 把多语言切换封装成扩展方法。

俺给Object加了一个扩展方法：String GetLabel(String key, String defaultValue). 该方法自动从俺自定义的资源文件中寻找key所对应的字符串，找到了则返回，找不到则返回defaultValue。

（2） 把一些常用的UI逻辑封装成扩展方法。

比如，删除时进行确认，并判断有没有选中项：

Code

获取DataGridView选中的项：

Code

（3） 将控件的默认值或默认行为设置几个自己常用的方案。这样，开发UI时，直接通过扩展方法选择相应的方案，而不是手动的一个个从VS的属性窗口去寻找，去一个个去调（很容易遗漏）：

Code

二、Mediator 模式

另一种复用策略是组合。
经常会遇到这样的情况：一个窗体或一个页面上有几个控件A、B、C，这A、B、C之间存在某种固定的行为模式。
直观上的考虑是使用用户控件。

使用用户控件有几个缺点：
（1） UI死板，难以调整
（2） Bug多（WebForm还好，WinForm自定义控件一复杂，VS就难以正确的渲染）
（3） 用户控件不是正交的，没法进一步组合。

那么，怎么办呢？
天空一声巨响，Mediator闪亮登场。

不得不承认，我以前小看了Mediator模式，将它打为二类设计模式（Strategy，Obverser，Facade是俺心中的一类设计模式，在俺心中，一类设计模式之外的模式都是渣。这里再挑衅一句：全部工厂模式都是渣。）
Mediator模式是对多个对象之间行为的抽象。关于这个模式，就只说这一句话，也没有UML图（对于俺这种程序员来说，UML就是渣一般的存在）。

下面举个例子，使用Mediator 对中间地带行为进行封装。

这个例子涉及到三个控件之间的联动：
有一个ComboBox控件显示类别列表，一个ListBox控件显示选中类别的子项列表，一个TextBox控件显示选中子项的简单介绍。然后，当双击某子项时，则自动选中该子项（遗憾的是，ListBox并不支持双击某子项的事件，得自己实现该逻辑）。

先定义一个类CategoryItem。代表类别或子项。

Code

然后，写一个 CategoryItemSelectorMediator（似乎叫CategoryItemSelectMediator更恰当）

Code

当我们期望某些对象或控件之间形成某种Mediator所规定的行为约束时，就new 一下这个Mediator，Bind一下，就OK了。

三、牢骚话

很不好意思的说，爬了这么多年的代码，俺还是不能理解什么是MVC、MVP，俺看不到理解这几个词对俺的代码有何帮助。俺只是看到了在现有的东东和要做的东东之间存在巨大的中间地带，这个中间地带有很多很多的重复劳动需要去消除。用扩展方法和Mediator清理中间地带后，世界清静了不少。

四、题外话

对于知识，俺觉得，还是掌握的越少越好——正应了伟人的那句话：

    知识越多越反动

当你掌握了面向对象的那些规则之后，设计模式你可以全部忘记了——那是枷锁。
当你掌握了DRY之后，面向对象的那些规则也可以全部忘记了——那是枷锁。
DRY就是Don't Repeat Yourself。用俺的话说，就是：不要复制和粘帖，那是邪恶滴。换一句话说就是，懒惰是程序员最佳的品质。
DRY是外语，不友好。“懒惰”歧义太多。还是俺的话最好理解：

对程序员来说，每一次的复制和粘帖都是在犯罪。

今天，你犯罪了吗？

补充：

这篇博客发出去之后，发现遗漏了一个观点。

有两种方法。

一种是拿着锤子去找钉子：学了一个东东，然后去找怎样去应用它。学一个模式，然后去全世界找实例。

一种是拿着钉子去找锤子：有一个问题，然后去找解决它的方法。用这个方式来看，用户控件和Mediator是同等的存在，虽然，它们分属不同的知识体系。

当你按一次Ctrl+C，按一次Ctrl+V时。说明你的程序必然存在不完美。如何去克服这种不完美。使用语法糖也好，设计模式也好，当猫道狗道全部用上也无法解决问题时再去Ctrl+C，Ctrl+V。长久以往，啥都理解了。

Ctrl+C， Ctrl+V，就是程序开发中的红灯。

本文转自xiaotie博客园博客，原文链接http://www.cnblogs.com/xiaotie/archive/2009/10/15/1583680.html如需转载请自行联系原作者

xiaotie 集异璧实验室(GEBLAB)