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

上传机制有一个很直观的好处，如果船基类又临时增加赛船子类， 我们在不修改已有代码的前提下轻松完成对原有软件的扩展，即"开放－封闭"原则(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类为受托方李律师，张三(商船类)称我要告王五（阻力计算委托），李律师胸脯一拍：没问题，这事我按民事诉讼程序(风阻力计算方法)来办。