ASP.NET入门随想之多态、接口与委托

曾几何时，我们居住的陆地沉睡在海底，大陆也紧密的联系在一起，千百年过去了七大洲的地壳板块在缓缓移动，喜马拉雅山在慢慢增高，世界在变，唯一不变的是变化。

　　■ 软件开发的悖论 - 把变化变成计划

　　在软件开发活动的过程中，常被一个悖论所缠绕：不写码就搞不清该做什么；搞不清做什么又不知道该如何写码。

　　人的思维是很随意的东西，不同的人，或同一个人的不同阶段，对同一件事情的看法都会有差异，可谓是远看成岭侧成峰，远近高低各不同。随意再加上变化，常常引起项目流产或工期大大拖延。

　　之所以会有软件工程，是因为想尽量挽救我们那白白死去的脑细胞和消逝的人民币。CIM/ISO官僚，每一个环节都要进行所谓科学管理与评估，质量差就返工，争取每一种构造活动只进行一次。难度在于开发活动很难定量计算，所谓评估常就是大家一起到酒桌上拼拼，一些活动初期的错误在后续无限放大；商业驱动的RUP有些瞎子摸象，要求用最短的时间拼出爱因斯坦粗糙的第一张凳子交给用户，得到确认后在此基础上不断循环改造，一直到用户满意的第N张为止，需要大量的用户参与，可是用户不是软件工程师，要他们来把握复杂的活动计划，难为他们。总之两者都有缺陷，修正错误和迭代开发是必然，所以软件架构设计伊始就要考虑适应需求变化，力将变化带来的影响减少到最小。 OO开发范式大致为：划分对象→抽象类→将类组织成为层次化结构(继承和合成) →用类与实例进行设计和实现几个阶段。在这个过程，合理使用OO语言的一些特性将影响软件对需求变化的适应力，其使用熟练度往往成为评价软件开发人员的标杆。

　　■ 尽可能远离switch - 多态与抽象类

　　OO思想的基础在于把具备状态和方法的对象看作系统组成的基本粒子，用粒子之间的相互作用(或通讯)来描述系统的行为。通常方法在在某个类的作用域中定义方法接口和实现，并用于修改类的状态，如：泰坦尼克.移动(方向)，这时方法是类的配角，为类服务，即类的方法。

　　类的方法可能会有多种形态，只要签名(返回值和参数列表)不同，我们可以通过方法重载来达到概念(方法名)统一，如：泰坦尼克.移动(方向)与泰坦尼克.移动(方向，水流)，这两种状况的实现不一样，但作为类的使用者概念而言，都是泰坦尼克在移动。而在面向过程时代，方法的多态往往是由switch语句来负责处理。

　　结构化语言初行之时，非结构化语言被猛烈攻击的焦点居然集中在一条语句--goto身上，说它破坏了程序的组织结构，仿佛它就是万恶之源；与之类似的是，十几年后OO语言风行之始，人们同样找到一条语句大肆抨击，称它为僵化的毒药，它就是switch语句。switch语句是典型的结构化编程思想，众多模块的公共属性被映射到标志变量值域上的一点，简单地排列在一块，如下例：

switch (船类型){ 　case "商船" 　　商船的移动计算方法; Break; 　case "战船" 　　战船的移动计算方法; Break; }

　　上例中，switch语句的问题在于它谋杀了众多船类移动计算方法之间的结构本质，缺乏对相似方法应有的抽象。后果是随处可见它那臃肿的身影。一旦需求变动，我们就不得不四处搜寻，一一修正。

　　在这里移动方法实际上是船类系的公共方法。作为类系的使用者，他必然希望象重载一样做到概念(方法名)统一，而通过方法的签名来区分是商船还是战船在移动，所以我们调整如下：

void 控制移动(船类 ship){ 　ship.移动; 　…… } 战船 俾斯麦 = new战船(); 商船 泰坦尼克 = new商船(); 控制移动(俾斯麦); 控制移动(泰坦尼克);

　　在控制移动(泰坦尼克)方法中，我们用商船的移动方法替换了ship.移动方法，其实这就是《随想六》提到的里氏替换原则，即子类型可以替换基型。类系方法的多态是由上传(upcast)机制来实现，如图7-1。与重载一样，由OO语言自动完成。


　　上传机制有一个很直观的好处，如果船基类又临时增加赛船子类， 我们在不修改已有代码的前提下轻松完成对原有软件的扩展，即"开放－封闭"原则(Open-Closed Principle)。如增加以下代码并不影响控制移动方法：

　　赛船 麦哲伦 = new赛船();
　　控制移动(麦哲伦);

　　只所以功能扩展不影响控制移动方法，是因为控制移动方法只依赖于船类系的基类。如果把一个类系的公共方法集中起来，定义成抽象类(abstract)，其它类只与抽象类发生依赖关系，只要抽象类的方法接口不变，其继承子类的内部调整不影响外界的使用，最大程度达到外界与这个类系的架构(这时指依赖关系)稳定。作为一个抽象类，它具备两个重要特征：一是方法只有接口定义没有实现，二是子类(非抽象类继承)必须实现抽象类的所有方法。抽象类不能实例化，也没有必要实例化，就一空架子折腾啥呀。

　　■ 我是主角 - 接口与委托

　　OO思想一般强调类为主角，方法是类的配角，尤其抽象类系，基类与所有子类是强耦合关系，它要是倒下了，人心就散了，队伍就难带了。一旦抽象类需要变动(增删改类系的公共方法)，就对一个软件架构的影响程度而言，不亚于俄罗斯对乌克兰天然气涨价给欧洲带来的振憾，有可能带来多米诺骨牌效应。 当方法不仅仅只是一个而是多个类系的公共行为的抽象时，我们就必须把配角方法升格为主角，让它来支配相关类系，做法是将公共方法接口独立出来，单独定义成接口(interface)，然后由相关类系一一实现，这时我们可以把其称为方法的类。所有外界与其关系不再建立在抽象类而是建立在接口之上，如图7-2。在定义接口的时候，注意不要让其过度臃肿，一个类对另外一个类的依赖性应当是建立在最小接口上。复杂的接口可以通过接口的多重继承或委托来分离。


　　之所以一步步地把方法从配角升格为主角，是因为我们希望将需求中不稳定的成分隔离出来，用相对稳定的成分作为框架来构造系统。而一般概念的生存周期要远远大于特殊概念，如：职位>总裁>方兴东，所以要依赖于抽象而不要依赖于具体，即依赖倒置原则（Dependence Inversion Principle），前面谈到的"开放－封闭"原则是其外延。

　　此外尽管方法从配角变为主角，其实现还是在该类的作用域中。有时方法更出格，委托类除了定义方法签名和通知其开工消息外，对方法的实现完全失去控制，它甚至到上台以后才知道今天的主角究竟是谁。这就是委托(delegate)机制。实质是类直接引用另一个类的方法，只要委托方法与受托方法接口一致，目的是彻底将方法的接口与实现分离。

class 商船{ 　//委托类 　private int 动力; 　private delegate int 阻力计算委托(); //定义委托 public void 移动(阻力计算委托 阻力){ 　　int 作用力 = 动力 -阻力(); 　　…… 　} } class Test{ 　//受托类 　private int 风阻力计算(){……}; 　static void main(){ 　　商船 泰坦尼克; 　　泰坦尼克.移动(new阻力计算委托(风阻力计算)) //委托实例 　} }

　　委托可以这么理解，上例中商船类为委托方张三，Test类为受托方李律师，张三(商船类)称我要告王五（阻力计算委托），李律师胸脯一拍：没问题，这事我按民事诉讼程序(风阻力计算方法)来办。

查看本文来源