曾几何时，我们的父辈接受到的对美好生活的描绘是：“楼上楼下、电灯电话”，三十年过去了，电灯电话早已已成为我们老百姓家中生活必需品，但美好生活似乎还有更多的内涵。沉重的七大洲地壳板块缓缓移动，挺拔的喜马拉雅山慢慢增高，世界在变，唯一不变的是变化。
■ 软件开发的悖论 – 把变化变成计划
■ 尽可能远离switch – 多态与抽象类
■ 我是主角 – 接口与委托
[ASP.NET入门随想七]主角与配角
——OO思想的多态、接口与委托
曾几何时，我们的父辈接受到的对美好生活的描绘是：“楼上楼下、电灯电话”，三十年过去了，电灯电话早已已成为我们老百姓家中生活必需品，但美好生活似乎还有更多的内涵。沉重的七大洲地壳板块缓缓移动，挺拔的喜马拉雅山慢慢增高，世界在变，唯一不变的是变化。
■ 软件开发的悖论 – 把变化变成计划在软件开发活动的过程中，常被一个悖论所缠绕：不写码就搞不清该做什么；搞不清做什么又不知道该如何写码。
人的思维是很随意的东西，不同的人，或同一个人的不同阶段，对同一件事情的看法都会有差异，可谓是远看成岭侧成峰，远近高低各不同。随意再加上变化，常常引起项目流产或工期大大拖延。
之所以会有软件工程，是因为想尽量挽救我们那白白死去的脑细胞和消逝的人民币。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语言自动完成。
上传机制有一个很直观的好处，如果船基类又临时增加赛船子类， 我们在不修改已有代码的前提下轻松完成对原有软件的扩展，即“开放－封闭”原则(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类为受托方李律师，张三(商船类)称我要告王五（阻力计算委托），李律师胸脯一拍：没问题，这事我按民事诉讼程序(风阻力计算方法)来办。
