1. 你通常怎样用多态?

假设我有一个类,里面有一个 PrintStatus 方法,用于打印实例的当前状态,我希望该类的派生类都带有一个 PrintStatus 方法,并且这些方法都用于打印其实例的当前状态。那么我会这样表达我的愿望:
 
// Code #01

class Base
{
 public virtual void PrintStatus()
 {
  Console.WriteLine("public virtual void PrintStatus() in Base");
 }
}

于是我可以写一个这样的方法:
 
// Code #02
  
public void DisplayStatusOf(Base[] bs)
{
 foreach (Base b in bs)
 {
  b.PrintStatus();
 }
}

bs 中可能包含着不同的 Base 的派生类,但我们却可以忽略这些“个性”而使用一种统一的方式来处理某事。在 .NET 2.0 中,XmlReader 的 Create 有这样一个版本:

public static XmlReader Create(Stream input);

你可以向 Create 传递任何可用的“流”,例如来自文件的“流”(FileStream)、来自内存的“流”(MemoryStream)或来自网络的“流”(NetworkStream)等。虽然每一中“流”的工作细节都不同,但我们却使用一种统一的方式来处理这些“流”。

2. 假如有人不遵守承诺...

DisplayStatusOf 隐含着这样一个假设:bs 中如果存在派生类的实例,那么该派生类应该重写 PrintStatus,当然必须加上 override 关键字:
 
// Code #03
 
class Derived1 : Base
{
 public override void PrintStatus()
 {
  Console.WriteLine("public override void PrintStatus() in Derived1");
 }
}

你可以把这看作一种承诺、约定,直到有人沉不住气...

// Code #04
 
class Derived2 : Base
{
 public new void PrintStatus()
 {
  Console.WriteLine("public new void PrintStatus() in Derived2");
 }
}

假设我们有这样一个数组: // Code #05

Base[] bs = new Base[]
{
 new Base(),
 new Derived1(),
 new Derived2()
};

把它传递给 DisplayStatusOf,则输出是:
 
// Output #01
 
// public virtual void PrintStatus() in Base
// public override void PrintStatus() in Derived1
// public virtual void PrintStatus() in Base

从输出结果中很容易看出 Derived2 并没有按照我们期望的去做。但你无需惊讶,这是由于 Derived2 的设计者没有“遵守约定”的缘故。

3. new:封印咒术

new 似乎给人一种这样的感觉,它的使用者喜欢打破别人的约定,然而,如果使用恰当,new 可以弥补基类设计者的“短见”。在 Creating a Data Bound ListView Control 中,Rockford Lhotka 就示范了如何封印原来的 ListView.Columns,并使自行添加的返回 DataColumnHeaderCollection 的 Columns 取而代之。

从 Output #01 中我们可以看到,new 只是把 Base.PrintStatus 封印起来而不是消灭掉,你可以解除封印然后进行访问。对于 Derived2 的使用者,解封的方法是把 Derived2 的实例转换成 Base 类型:
 
// Code #06
 
Base d2 = new Derived2();
d2.PrintStatus();
 
// Output #02
 
// public virtual void PrintStatus() in Base
而在 Derived2 内部,你可以透过 base 来访问:

// Code #07

base.PrintStatus();

这种方法是针对实例成员的,如果被封印的成员是静态成员的话,就要透过类名来访问了。

4. 假如 Base.PrintStatus 是某个接口的隐式实现...

假如 Base 实现了一个 IFace 接口:

// Code #08
 
interface IFace
{
 void PrintStatus();
}

class Base : IFace
{
 public virtual void PrintStatus()
 {
  Console.WriteLine("public virtual void PrintStatus() in Base");
 }
}

我们只需要让 Derived2 重新实现 IFace:
 
// Code #09

class Derived2 : Base, IFace
{
 public new void PrintStatus()
 {
  Console.WriteLine("public new void PrintStatus() in Derived2");
 }
}

Derived1 保持不变。则把:
 
// Code #10
 
IFace[] fs = new IFace[]
{
 new Base(),
 new Derived1(),
 new Derived2(),
}

传递给:
 
// Code #11

public void DisplayStatusOf(IFace[] fs)
{
 foreach (IFace f in fs)
 {
  f.PrintStatus();
 }
}

输出结果是:
 
// Output #03
 
// public virtual void PrintStatus() in Base
// public override void PrintStatus() in Derived1
// public new void PrintStatus() in Derived2

从输出结果中,我们可以看到,虽然 Derived2.PrintStatus 应用了 new,但却依然参与动态绑定,这是由于 new 只能割断 Derived2.PrintStatus 和 Base.PrintStatus 的联系,而不能割断它与 IFace.PrintStatus 的联系。我在 Derived2 的定义中重新指定实现 IFace,这将使得编译器认为 Derived2.PrintStatus 是 IFace.PrintStatus 的隐式实现,于是,在动态绑定时 Derived2.PrintStatus 就被包括进来了。

5. 谁的问题?

我必须指出,如果 Base(Code #01)和 Derived2(Code #04)同时存在的话,它们俩其中一个存在着设计上的问题。为什么这样说呢?Base 的设计者在 PrintStatus 上应用 virtual 说明了他希望派生类能透过重写这一方法来参与动态绑定,即多态性;而 Derived2 的设计者在 PrintStatus 上应用 new 则说明了他希望割断 Derived2.PrintStatus 和 Base.PrintStatus 之间的联系,这将使得 Derived2.PrintStatus 无法参与到 Base 的设计者所期望的动态绑定中。如果在 Base.PrintStatus 上应用 virtual(即对多态性的期望)是合理的话,那么 Derived2.PrintStatus 应该换用另外一个名字了;如果在 Derived2.PrintStatus 上应用 new(即否决参与动态绑定)是合理的,那么 Base.PrintStatus 应该考虑是否去掉 virtual 了,否则就会出现一些奇怪的行为,例如 Output #01 的第三行输出。

假如继承体系中多态性行为的期望是合理的话,那么更实际的做法应该是把 Base 定义成这样:
 
// Code #12
 
abstract class Base
{
 public abstract void PrintStatus();
}

而原来 Base 中的实现应该下移到一个派生类中: // Code #13

class Derived3 : Base
{
 public override void PrintStatus()
 {
  Console.WriteLine("public override void PrintStatus() in Derived3 [originally implemented in Base]");
 }
}

这样,Derived2.PrintStatus 将使得编译无法完成,从而迫使其设计者要么更改方法的名字,要么换用 override 修饰。这种强制使得 Derived2 的设计者不得不重新考虑其设计的合理性。

假如继承体系中多态性行为的期望不总是合理呢?例如 Stream 有这样一个方法:

public abstract long Seek(long offset, SeekOrigin origin);

现在假设我有一个方法在处理输入流时需要用到 Stream.Seek:
 
// Code #14
 
public void Resume(Stream input, long offset)
{
 // 
 input.Seek(offset, SeekOrigin.Begin);
 // 
}

当我们向 Resume 传递一个 NetworkStream 的实例,Resume 将会抛出一个 NotSupportedException,因为 NetworkStream 不支持 Seek。那么这是否说明 Stream 的设计有问题呢?

设想 Resume 是一个下载工具进行断点续传的方法,然而,并不是所有的服务器都支持断点续传的,于是,你需要首先判断输入流是否支持 Seek 操作,再决定如何处理输入流:
 
// Code #15
 
public void Resume(Stream input, long offset)
{
 if (input.CanSeek)
 {
  // 
  input.Seek(offset, SeekOrigin.Begin);
  // 
 }
 else
 {
  // 
 }
}

如果 CanSeek 为 false,那就只好从头来过了。

实际上,我们并不能保证任何 Stream 的派生类都能够支持某个(些)操作,我们甚至不能保证来自同一个派生类的所有实例都支持某个(些)操作。你可以设想有这样一个 PriorityStream,它能够根据当前登录账号的权限来决定是否提供写操作,这使得拥有足够权限的人才能修改数据。或许 Stream 的设计者已经预料到这类情况的发生,所以 CanRead、CanSeek 和 CanWrite 就被加入到 Stream 里了。

值得注意的是,Code #07 的 Derived2 可能是一个很糟糕的设计,也可能是一个很实用的设计。在本文,它是一个很糟糕的设计,如果你足够细心,你会察觉到 Derived2 的设计者希望 Derived2.PrintStatus 绕过 Base.PrintStatus 而直接和 IFace.PrintStauts 进行关联,表面上这没什么不妥,但实质上 Base.PrintStatus 和 IFace.PrintStauts 在约定上是同质的,这意味着如果与 IFace.PrintStauts 进行关联就等于承认自己和 Base.PrintStatus 是同质的,这样的话,为什么不直接在 Derived2 里重写 PrintStatus 呢?在《基类与接口混合继承的声明问题》中,我示范了一个实用的设计,用 new 和接口重新实现(Interface reimplementation)来纠正非预期的多态行为。

6. 最后...

当我的朋友拿着问题来找我时,我通常都不会直接给出我的答案,而是尽我的能力向他提供足够多的可用信息,以便他能够根据他所面临的实际情况作出处理,毕竟,我不会比他更了解他的问题,而他也应该形成他自己的关于他的问题的思考。我希望浪子能用自己的答案回答他所提出的问题,因为只有这样,那些知识才真正属于他,并且我也相信本文已经提供了足够多的可用信息。

 

C# 多态与new关键字的更多相关文章

  1. 面向对象的三大特征——封装、继承、多态(&常用关键字)

    一.封装 Encapsulation 在面向对象程式设计方法中,封装是指,一种将抽象性函式接口的实作细节部份包装.隐藏起来的方法. 封装的概念(针对服务器开发,保护内部,确保服务器不出现问题) 将类的 ...

  2. java基础14 多态(及关键字:instanceof)

    面向对象的三大特征: 1.封装   (将一类属性封装起来,并提供set()和get()方法给其他对象设置和获取值.或者是将一个运算方法封装起来,其他对象需要此种做运算时,给此对象调用) 2.继承   ...

  3. 深入理解OOP(三):多态和继承(动态绑定和运行时多态)

    在前面的文章中,我们介绍了编译期多态.params关键字.实例化.base关键字等.本节我们来关注另外一种多态:运行时多态, 运行时多态也叫迟绑定. 深入理解OOP(一):多态和继承(初期绑定和编译时 ...

  4. 深入浅出OOP(三): 多态和继承(动态绑定/运行时多态)

    在前面的文章中,我们介绍了编译期多态.params关键字.实例化.base关键字等.本节我们来关注另外一种多态:运行时多态, 运行时多态也叫迟绑定. 运行时多态或迟绑定.动态绑定 在C#语音中,运行时 ...

  5. c# 继承,多态,new /overrid 区别, 引用父类的方法

    好久没碰c#了,偶尔需要制作点小工具.为了一个灵活的架构设计,需要对继承/多态有比较深刻的理解. 不料忘得差不多了,好吧,再来回忆下.直接上代码了,如下: using System; using Sy ...

  6. JAVA基础复习与总结<一> 对象与类的概念_内部类_继承与多态

    一.对象与类 类:类是一个模版,它描述了一类对象的行为和状态. class animal { private int color; private int size; public void eat ...

  7. java中面向对象的一些知识(二)

    一. 封装的讲解 什么是封装?为什么要封装?怎么实现封装? 封装的目的是为了提高程序的安全性.封装就是把不想让第三者看的属性,方法隐藏起来. 封装的实现方法是: 1.修改属性的可见性,限制访问. 2. ...

  8. 【C#】第3章学习要点(二)自定义类和结构

    分类:C#.VS2015 创建日期:2016-06-19 使用教材:(十二五国家级规划教材)<C#程序设计及应用教程>(第3版) 一.要点概述 别人提供的类都是为了简化你的工作量用的,可是 ...

  9. 9月java货车版速记

    运算符的优先级java自带的方法正则表达式数组和二维数组:数组遍历,填充数组,数组排序,复制数组,数组查询数组算法:冒泡,选择,反转,快速类和对象:封装,继承,多态,this关键字,抽象类和接口重写和 ...

随机推荐

  1. 11gR2 ASM RAC + ASM RAC dataguard配置

    1.环境说明 --primary端配置 Primary RAC Node1 Node2 Public IP 192.168.56.120 192.168.56.122 Private IP 10.0. ...

  2. spring不同环境下用不同的配置文件

    @Configuration @PropertySource("xx-${spring.profiles.active}.properties") public class Top ...

  3. Java面向对象_数据结构之链表

    链表:是一种常见的基础数据结构,是一种线性表,但是并不会按线性的顺序存储数据,而是在每一个节点里村到下一个节点的指针. 在链表数据结构中,需要使用到递归算法.递归算法是一种直接或间接地调用自身算法的过 ...

  4. (转)CentOS最大文件描述符限制更改

    CentOS最大文件描述符限制更改 原文:https://www.cnblogs.com/TonyXiaoClub/p/4747736.html 系统级的限制:/proc/sys/fs/file-ma ...

  5. (转)由su和su -的区别谈学习linux运维方法

    由su和su -的区别谈学习linux运维方法 原文:http://blog.51cto.com/oldboy/1053606 由su和su -的区别谈学习linux运维方法一例 老男孩Linux培训 ...

  6. js 和C# ashx之间数组参数传递问题

    js在进行ajax提交时,如果提交的参数是数组,js无法直接进行提交,及时提交上去,解析也是比较麻烦 ajax在提交数组时,需要设置参数:  traditional: true,  //参数作为数组传 ...

  7. 在MFC对话框中快速集成三维控件

    在MFC的对话框中可以方便的集成AnyCAD三维控件(c++版本),遵循一下几步: 1.在对话框资源中增加一个Static控件,ID为IDC_STATIC_3D,并且把它的Notify属性设置为Tru ...

  8. 华为云kafka POC 踩坑记录

    2019/03/08 18:29 最近在进行华为云相关POC验证,个人主要负责华为云DMS kafka相关.大致数据流程是,从DIS取出数据,进行解析处理,然后放入kafka,再从kafka中取出数据 ...

  9. Java并发基础:线程的创建

    线程的创建和管理: 1.应用Thread类显式创建.管理线程 2.应用Executor创建并管理线程. 定义任务: 无返回的任务:实现Runnable接口并编写run()方法. 有响应的任务:实现Ca ...

  10. 在Magento System Configuration页面添加配置项

    以 Jp_Coupon 模块为例: 目标: 在 System configuration 页面添加一个 JP tab, 在JP中添加 Coupon section, 然后给 Coupon sectio ...