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

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

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

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

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

　　之所以会有软件工程，是因为想尽量挽救我们那白白死去的脑细胞和消逝的人民币。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语言自动完成。