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语言自动完成。

20060111101354_1.gif

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

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

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

  ■ 我是主角 - 接口与委托

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

20060111101339_2.gif

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

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

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


  委托可以这么理解,上例中商船类为委托方张三,Test类为受托方李律师,张三(商船类)称我要告王五(阻力计算委托),李律师胸脯一拍:没问题,这事我按民事诉讼程序(风阻力计算方法)来办。
阅读更多
个人分类: asp.net
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭