深刻浅出话多态(下)——牛刀小试
小序
英格兰走了……巴西的表演尚未开场。闲着也是闲着,我把下篇写出来。
正文
一.多态的现实意义
若是一个编程元素没有能够应用在软件工程中的现实意义,那将是一件不可容忍的事情。同理,若是你不了解一个编程元素的现实意义、不知道在编程时应该怎么用,就不能说本身懂得了这个编程元素。
个人编程经验实在很少,就我我的感受,多态最大的现实意义在于“代码的简化”。
多态为何能简化代码捏?
先让咱们用一句话归纳多态的实现:首先要一我的父类,在这个父类的成员中,有一个virtual的(能够被子类重写的)方法。而后,有N多子类继承了这个父类,而且用override重写了父类的那个virtual方法——此时已经造成了一个扇形的多态继承图。固然,若是用做“父类”的是一个接口,那么在子类中就不是“重写”方法,而是“实现”方法了。
一旦这个“继承扇”造成了,咱们应该意识到——不管是父类仍是子类,他们都有一个同名的方法,并且此同名方法在各个子类中是“个性化”的——它重写了父类的方法、而且子类与子类之间的这个同名方法也各不相同。
在程序的编写期,程序员总要预期用户可能进行的各类操做——好比对“继承扇”中每一个子类的操做。程序编译完成、成为可执行文件并交付用户后,程序员就不能再控制程序了,这时候程序只能遵从用户的摆布。假设没有多态,那么为了让用户在调用每一个子类的时候程序都能有正确的响应,程序员不得不为每一个子类在内存中建立一个实例——这样一来,程序复杂度增长的同时,性能也降低了。还好,这只是个假设……
OK,让咱们仍是来拿代码说事儿吧。下面给出两段代码,对比显示了多态的巨大优越性。
代码1:非多态排比代码
using System;
using System.Collections.Generic;
using System.Text;
namespace Sample
{
class OptimusPrime //博派老大擎天柱
{
public void Transform()
{
Console.WriteLine("Transform to a TRUCK...");
}
}
class Megatron //狂派老大威震天
{
public void Transform()
{
Console.WriteLine("Transform to a GUN...");
}
}
class Bumblebee //大黄蜂
{
public void Transform()
{
Console.WriteLine("Transform to a CAR...");
}
}
class Starscream //红蜘蛛
{
public void Transform()
{
Console.WriteLine("Transform to a FIGHTER...");
}
}
class Program //主程序类
{
static void Main(string[] args)
{
string number = string.Empty;
//为每一个类准备一个实例
OptimusPrime transformer1 = new OptimusPrime();
Megatron transformer2 = new Megatron();
Bumblebee transformer3 = new Bumblebee();
Starscream transformer4 = new Starscream();
while (true) //无限循环
{
Console.WriteLine("Please input 1/2/3/4 to choose a transformer...");
number = Console.ReadLine();
switch (number) //根据用户选择,做出响应
{
case "1":
transformer1.Transform();
break;
case "2":
transformer2.Transform();
break;
case "3":
transformer3.Transform();
break;
case "4":
transformer4.Transform();
break;
default:
Console.WriteLine("Do you want a TRACTOR ??");
break;
}
}
}
}
}
代码分析:
1. 一上来是4个独立的类(相信这4位人物你们都不陌生吧……),这4个类有一个同名方法:Transform()。虽然同名,但各自的实现倒是“个性化”的、彻底不一样的——咱们这里只用输出不一样的字符串来表示,但你想啊——一样是有胳膊有腿的一个你们伙,变成汽车的方法跟变成飞机、变成枪怎么可能同样呢?
2. 进入主程序后,先是为每一个类实例化一个对象出来,以备用户自由调用。这么作是很占内存的,若是为了优化程序,对每一个类的实例化是能够挪到switch的每一个case分支里的。
3. 一个无限循环,能够反复输入数字……
4. switch…case…根据用户的需求来调用合适的Transformer的Transform方法。
代码2:使用多态,简化代码
using System;
using System.Collections.Generic;
using System.Text;
namespace Sample
{
class Transformer //基类
{
public virtual void Transform()
{
Console.WriteLine("Transform to a ??? ???...");
}
}
class OptimusPrime : Transformer //博派老大擎天柱
{
public override void Transform()
{
Console.WriteLine("Transform to a TRUCK...");
}
}
class Megatron : Transformer //狂派老大威震天
{
public override void Transform()
{
Console.WriteLine("Transform to a GUN...");
}
}
class Bumblebee : Transformer //大黄蜂
{
public override void Transform()
{
Console.WriteLine("Transform to a CAR...");
}
}
class Starscream : Transformer //红蜘蛛
{
public override void Transform()
{
Console.WriteLine("Transform to a FIGHTER...");
}
}
class Program //主程序类
{
static void Main(string[] args)
{
string number = string.Empty;
//只准备一个变量便可,而且不用实例化
Transformer transformer;
while (true) //无限循环
{
Console.WriteLine("Please input 1/2/3/4 to choose a transformer...");
number = Console.ReadLine();
switch (number) //根据用户选择,做出响应,运行期"动态"实例化
{
case "1":
transformer = new OptimusPrime();
break;
case "2":
transformer = new Megatron();
break;
case "3":
transformer = new Bumblebee();
break;
case "4":
transformer = new Starscream();
break;
default:
transformer = null;
break;
}
if (transformer != null) //这里是本程序的核心
{
transformer.Transform();
}
else
{
Console.WriteLine("Do you want a TRACTOR ??");
}
}
}
}
}
代码分析:
1. 为了展现多态效果,先装备了一个基类。这个基类是一个常规的类——能够实例化、调用其方法。不过,使用抽象类或者接口来展现多态效果也彻底没有问题,所以,你把Transformer类替换成下面两种形式也是能够的:
(A)以抽象类作基类
abstract class Transformer //基类,这是一个抽象类,方法只有声明没有实现
{
abstract public void Transform();
}
(B)以接口作基类
interface Transformer //基接口,方法只有声明没有实现
{
void Transform();
}
注意:若是使用的是基接口而不是基类,那么实现基接口的时候,方法再也不须要override关键字。缘由很简单,接口中的方法是没有“实现”的,因此只须要“新写”就能够了、不用“重写”。以下:
class OptimusPrime : Transformer //博派老大擎天柱
{
public void Transform()
{
Console.WriteLine("Transform to a TRUCK...");
}
}
花絮:
记得有一次公开课上,一个兄弟问我:究竟是用常规类合适,仍是用抽象类或者用基接口合适呢?如何判断、如何在工程中应用呢?我感受这个问题问的很是好——这个已经不是C#语言所研究的范畴了,而是软件工程的范畴,确切地说,这是“设计模式”(Design Pattern)的范畴。当你已经对类的封装、继承、多态了如指掌后,不知足于这种小儿科的例子程序而打算用这些知识写出漂亮的软件工程时,那么你会发现:如何设计类、什么应该被设计成类、什么不该该,与耦合,类与类之间如何继承最稳定、最高效,类与类之间如何平衡内聚……这些问题都很是重要却又让你感受无从下手。那么OK,去看《设计模式》吧,去学习UML吧!恭喜你,你上了一个大台阶!
2. 在本例中,只声明了一个多态变量,并且没有实例化。实例化的步骤挪到case分支里去了。我记得有的书里管这样的形式叫“动态实例化”。
3. switch…case…分支中,根据用户的选择实例化transform引用变量。
4. 最后的if…else…是程序的核心。在if的true分支里,由于各种的Transform()方法是同名并且是virtual/override继承的,因此可以体现出多态性。
二.牛刀小试
光写上面那种没什么实际用处的例子程序还真没多大意思,也就唬弄唬弄新手、讲讲原理还行。下面这个例子是多态在实际应用中的一个例子。这个例子在《深刻浅出话事件》里提到过,是有关于WinForm程序的事件中那个object类型的sender的。
OK,让咱们来考虑这样一种状况:我在窗体上放置了50个Control和一个ToolTip。如今要求当鼠标指向某一个Control的时候,ToolTip要显示当前所指Control的全名(Full Name)。
呵呵,这个听起来并不难,对吧!你可能会这样想:
1. 得到当前Control的名字,能够用这个Control的ToString()方法。
2. 在每一个Control的MouseEnter事件里,让ToolTip显示上一步所得到的字符串就OK了。
3. 好比button1的MouseEnter事件响应函数写出来就应该是这样的:
private void button1_MouseEnter(object sender, EventArgs e)
{
string fullName = button1.ToString();
toolTip1.SetToolTip(button1, fullName);
}
而comboBox1的MouseEnter事件响应函数则是:
private void comboBox1_MouseEnter(object sender, EventArgs e)
{
string fullName = comboBox1.ToString();
toolTip1.SetToolTip(comboBox1, fullName);
}
唔……窗体里有50个Control,你怎么办呢?
噢!你说能够用“复制/粘贴”而后再改动两处代码?
真是个好主意!!不过,你打算在什么地方出错呢?这种“看起来同样”的复制+粘贴,是Bug的一大来源。何况我这里只有50个Control,若是是500个,你打算怎么办呢?
佛说:前世的500次回眸,换得此生的1次擦肩而过;可他没说此生的500次Ctrl+C/Ctrl+V能在下辈子奖你个鼠标啊:P
OK,我知道你有决心和毅力去仔细完成50次正确的Ctrl+C/Ctrl+V而且把两处代码都正确改完。当你完成这一切以后,市场部的兄弟告诉咱们——客户的需求升级了!客户要求在鼠标移向某个Control时不但要显示它的Full Name,并且ToolTip的颜色是随机的!!
>_< …… @#^&(#$%^@#
50处的修改,不要漏掉喔……程序员吐吧吐吧,不是罪!
……拜OO之神所赐,咱们有多态……噩梦结束了。让咱们看看多态是如何简化代码、加强可扩展性的。
首先打开MSDN,我要Show你一点东西。请你分别查找Button类、TextBox类、ListBox类、ComboBox类……它们的ToString()方法。是否是均可以看到这样一句注释:
l ToString Overridden. (这是Button类的,是重写了父类的。)
l ToString Returns a string that represents the TextBoxBase control. (Inherited from TextBoxBase.)(这是TextBox的,说是从TextBoxBase继承来的,咱们追查一下。)
l ToString Overridden. Returns a string that represents the TextBoxBase control.(这是TextBoxBase的,也是重写了父类的。TextBox继承了它,因此仍然是重写的。)
l ToString Overridden. Returns a string representation of the ListBox. (这是ListBox的,也明确指出是重写的。)
……
这些Control都是重写的谁的ToString()方法呢?其中的细节我就不说了——这这个重写链的最顶端,是“万类之源”——Object类。也就是说,在Object类中,就已经包含了这个ToString()方法。Object类在C#中正好对应object这个Keyword。
一切问题都解决了!让咱们用多态来重构前面的代码!
1. 手动书写(或者改造某个Control的MouseEnter响应函数),成为以下代码:
private void common_MouseEnter(object sender, EventArgs e)
{
//用户的第一需求:显示ToolTip
string fullName = sender.ToString();
Control currentControl = (Control)sender;
toolTip1.SetToolTip(currentControl, fullName);
//用户的第二需求:随机颜色
Color[] backColors = new Color[] { Color.CornflowerBlue, Color.Pink, Color.Orange };
Random r = new Random();
int i = r.Next(0, 3);
toolTip1.BackColor = backColors[i];
//用户的第N需求:……
}
2. 将这个事件处理函数“挂接”在窗体的每一个Control的MouseEvent事件上,方法是:在“属性”面板里切换到Control的“事件”页面(点那个小闪电),而后选中MouseEvent事件,再点击右边的向下箭头,在下拉菜单中会出现上面咱们手写的函数——选中它。如图:
3. 为每个Control的MouseEvent事件挂接这个响应函数。一个简短的、可扩展的程序就完成了!
代码分析:
1. 函数之因此声明成:
private void common_MouseEnter(object sender, EventArgs e){…}
是为了与各Control的MouseEnter事件的委托相匹配。若是你不明白为何这样作,请仔细阅读《深刻浅出话事件》的上下两篇。
2. 核心代码:
string fullName = sender.ToString();
体现了多态。看似是sender的ToString()方法,但因为各个类在激发事件的时候,其实是以this的身份来发送消息的,this在内存中指代的就是一个具体的Control——若是是button1发送的消息,那么这个this在内存中就是指向的button1,只不过指向这块内存的引用变量是一个object类型的变量——典型的多态。又由于Button类继承自Object类,而且重写了Object的ToString()函数,因此在这里调用sender.ToString()实际上就调用了button1.ToString()。
3. 显式类型转换,为toolTip1的SetToolTip()函数准备一个参数:
Control currentControl = (Control)sender;
其实,这也是多态的体现:子类能够看成任意其父类使用。sender虽然是一个object类型的变量,但它其实是指向内存中的一个具体的Control实例——MouseEnter事件的拥有者(好比一个Button的实例或者一个TextBox的实例)。而Button、TextBox等类的父类就是Control类,因此彻底能够这么用。
4. 后面的代码就很是简单了,不说了。
至此,一个结构清晰,代码简单(只有原来的1/50长度,操做也为原来的1/20不到),便于维护并且扩展性极佳的程序就新鲜出炉了!没有多态,这是不可能实现的。
做业:
本身动手把这个WinForm程序完成,而且确保本身可以分析清楚每句代码的含意。
花絮:
现实当中,WinForm程序的一大部分代码都是由Visual Studio 2005为咱们写好的,鳞次栉比、很是好看——但初学者常被搞的晕头转向。没别的办法:大胆打开那些代码、仔细察看、动手跟踪跟踪、修改修改——别怕出错!经验大都是从错误中萃取出来的精华,有时候几十个错误才能为你换来那么一丁点领悟。高手不只仅是比咱们看书多,更重要是犯的错比咱们多,呵呵……
唉……长舒一口气。
最后我想说的是:要想读懂这些文章,首先要慢慢读——我写它的时候思路是清清楚楚的,但个人思想是个人思想,理解它的时候要一句一句看,说真的,错过一两个字都有可能读不懂。还有就是代码,必定要本身敲一遍。
若是你们有什么疑问,别客气,在后面跟帖发问就是了。只要有时间,我会一一做答。若是我有哪里写的不对,也请各位高手多多指教,我会马上更正。
到此为止,这篇又臭又长的文章能够OVER了——砖我是抛出去了,等您的玉呢!
OVER
下期预告:《深刻浅出话反射》