Extension Method之于C# 3.0就如同Prototype之于JavaScript。
二、如何在C# 2.0中解决Type的扩展性
我们一个完全一样的问题从弱类型、解释型的编程语言JavaScript迁移到C#这种强类型、编译型的语言上来。我们先看看在不能借助Extension
Method这一新特性的C# 2.0中,我们是如何解决这一问题。
我们先来看看如何对一个Interface进行扩张。假设我们有如下的一个IVector interface的定义:
public interface IVector
{
double X { get; set; }
double Y { get; set; }
} |
我们希望的是如何对这个Interface进行扩展,为之添加一个Adds Method执行向量相加的运算。我们唯一的解决方案就是直接在这个Interface中添加一个Adds成员:
public interface IVector
{
double X { get; set; }
double Y { get; set; }
IVector Adds(IVector vector);
} |
由于Interface和实现它的Type的紧密联系:所以实现了某个Interface的Type必须实现该Interface的所有方法。所以,我们添加了Adds
Method,将导致所有实现它的Type的重新定义和编译,在很多情况下,这种代价我们是负担不起的:比如在系统的后期维护阶段,对系统的进行局部和全部的重新编译,将很有可以导致一个正常运行的系统崩溃。Interface的这种局限性在面向抽象设计和编程中应该得到充分的考虑,这也是我们在很多情况下宁愿使用Abstract
Class的一个主要原因。
上面说到了对Interface的扩展,会出现必须实现Interface的Type进行改动的风险。我想有人会说,对Class尽心扩展就不会出现这样的情况了吧。不错,Class的继承性确保我们在Parent
class添加的Public/Protect能被Child Class继承。比如:如果Vector是一个Super
Class:
public class Vector
{
private double _x;
private double _y;
public double X
{
get {return this._x;}
set { this._x = value;}
}
public double Y
{
get { return this._y;}
set {this._y = value;}
}
} |