[ASP.NET入门随想六]大航海家——OO思想的类间关系

    多隆云：我和韦春花的关系是很纯洁的；网易称其和迷蝶女友的关系是培训双向选择制；杨振宁言《易经》思想阻碍了中国近代科学的发展；逻辑学家论：概念间的关系有五种，即同一、包含、交叉、分离、互斥。而康托尔却认为：关系是有序偶。

■ 我要懒+笨 - 程序设计的终极目标
 
　　前不久CSDN社区里出现题为《这样的程序员是否算是一个合格的程序员？》的热贴，楼主言一手下编码花时间比别人多但代码规范健壮，设问这样的程序员是否可以留用且如何用？顿时掀起一片哗然，展开在中国这个特定的环境下何为程序设计目标及相关项目管理之讨论。心灵捕手运用老毛《矛盾论》之手法分析："这个是市场和程序员的矛盾"，称"如果是小公司的话就别谈什么发展……时间为第一生产力……如果不是……就先解决管理和预算问题"，我不禁开始叹服其处理方法之老辣。

　　撇开市场因素不谈，程序设计的首要目标是去成功解决一现实问题。特别要注意的是，这个现实问题往往是动态的、随着时间的变化而变化的，所以我们的代码要足够健壮，以适应这个变化过程，而不应把目标定位在解决某一个静态点上的现实问题；其次代码及其结构应该是简洁的，只有简洁才能使编写容易、修改容易、维护容易，最大程度地节约成本；再则代码应该能够重复使用，贪婪的想法是代码不仅能够在一个现实问题中重用以减少重复劳动，还能在不同现实问题的交叉部份重复使用；最后因为人对世界的认识是一个迭代过程和现实问题在不断变化这两个因素，所以程序应该是不影响原来代码的前提下容易扩展。

    理论上说理解"万物皆对象，事事要封装"，综合面对过程的经验，你已经可以开始动手解决任何一个现实问题，但你会发现在整个开发过程中，仅凭目前的知识和见解，自己会被大量繁杂问题所缠绕，直至放弃为止，但这些原本完全可以避免！不管是这理论还是那设计模式，所有前人经验总结的终极目标无非就是让程序设计变成更简洁、更容易、更快捷，明白这点，许多杰出的程序大师为何号称自己是"懒+笨"之人也就不难理解。

■ 分离关系- 类的封装与依赖

　　这个世界的事物不可能象一个个鲁宾逊孤岛散落在一望无际的海洋中，老死不相往来。相反，即使是中国最边远的墨脱县，也依然与祖国保持着千丝万缕的关系。《随想五》中我们知道如何把现实空间的事物整理成对象并抽象成类，接下来梳理一下它们之间的关系。

　　首先我们以程序设计目标的视角来关注封装的意义。站在航海者(类的使用者)的角度来看，他不必要了解岛屿的地理、社会等内部结构(迪米特法则Law of Demeter)，而只需知道岛屿生产和需要什么(类的功能)、找谁买卖(public成员接口)就行了，知道这些就能很快搭建起一个商业网络(设计应用程序)。而作为岛屿的统治者(类的实现者)，他不必关注外界的风风雨雨，只需专注于岛屿内的生产和消费管理，统治者把这种现象称之为高内聚。

　　封闭大大简化了程序设计的复杂度，类间交流是通过一个狭窄的、经过良好限定的接口进行以保证类的可靠性。一方面类的使用者收集类快速开发程序，并且不试图改变类的内部结构，另一方面类的实现者在不修改public成员接口的前提下可以自由地修改内部工作方式。

　　但类的单独存在没有任何意义！最普通的关系是某个类的实例使用另一个类的实例，如果商船泰坦尼克号需要夏威夷岛提供货物，那么我们称商船依赖(Dependency)于岛屿提供货物，如图1所示，而随之而来的问题是，如果夏威夷岛内部动乱(类的实现者修改public成员接口)，将直接影响泰坦尼克号的正常工作，我们也将不得不重新组织商船类的内部结构以适应变化，前功尽弃。耦合是类间依赖程度的量度，对于变化可能性大的类在处理依赖关系时要尽量避免高耦合。  

 
■ 概念的包含与交叉 - 类的合成与继承

　　笨人是无法理解一个塞满各种复杂功能的对象，所以类的第一设计原则是单一，对应问题空间中的一个概念。如果所对应的概念包含其它概念，为整体/ 部分关系，称之为"has-a"，我们就将这几个类的实例合成(composition)一个新类。例如商船都有动力装置，那么我们就实例化一个动力装置类，加上除动力装置范畴以外的其它属性和方法，即合成商船类，如图2。合成具有极大的灵活性，且不破坏类的封装。所以我们要尽量使用合成，少用下面介绍的继承(合成复用原则Composite Reuse Principle)。 

 　　小时候的娱乐方式比较少，映入眼框的除了山水外，最多的莫过于五六十年代战争题材的老电影，里头人物脸谱化得严重，以至于我总认为，这个世界只有两种人--好人和坏人，如果这个观点成立，那么合成将一往无前。但这个世界上，并不全是整体都由部份简单叠加。现在让我们假设这个世界的船只有两种用途：商船和战船，从概念的角度来看，它们有相拟性，即概念交叉，如图6-3左，同时它们也具有各自的特点，如果我们只是简单地将商船和战船分别抽象成两个类，那么将出现大量的类成员重复，所以需要构造一个机制来反映两个概念的交叉关系，这就是继承（inheritance）的由来，称之为"is-a"。
            

　　继承的特点是具有层次性，从图的外形来看很象家谱树，但用家谱树来比喻继承是愚蠢的，并没有真正揭示继承的实质，继承的过程，就是从一般到特殊的过程，如图3右所示。传说中人类都是由非州一古猿的后代，事实与否我们先不讨论，但与之类似的是，如果层层抽象，.NET的所有类都直接或间接派生于同一个基类--Object类。

　　类的继承最直观的用处在于复用，.NET技术给我们第一映像就是MS公司工程师们经过长期实践提炼出的五千多个公共类，对于应用而言，它几乎涵盖了目前为止所有领域的一般化概念。在此基础上通过适当的继承与合成，我们很快就能构架出属于自己的类系。

　　我们再以成员集合的观点看待类，对于合成而言，其成员集合如下：
　　商船{位置，船向，动力装置{动力值}，移动(方向)}
引用动力值需要如此表达：商船.动力装置.动力值(你可以尝试一下把"."读成"的")，而对继承而言，其成员集合如下：
　　·商船{最大运载量，装载(货物)，移动(方向)}
　　·战船{火力值，战斗(船)，移动(方向)}
可以看出船类的public成员变成商船类的public成员，表达为：商船.移动，而船类的private成员在商船类中被隐藏。这么处理的依据是：因为船能移动，商船是船，所以商船也能移动(著名的苏格拉底三段论)。有时我们希望派生类能访问基类的某个成员但又对类以外的世界隐藏，如船的速度，各种种类的船都应该有速度，所以速度应该是基类成员，但我们不希望外界因素来直接修改速度值以破坏速度的计算机制(其同时受内外因素影响，由船的移动方法来计算)，所以我们引入第三个访问控制符protected来修饰该类成员。

　　战船有一个有趣的方法：战斗(船)，接口的参数是船类的一个实例，也就是说战船可以和任何一种船战斗，甭管是你商船还是战船，所以我们可以这么使用该方法: 俾斯麦.战斗(泰坦尼克号)，即子类型可以替换基类型(依然可以用苏格拉底三段论来证明这个逻辑)，这种替换方法称之为里氏代换原则(Liskov Substitution Principle)，作用是减小方法实现的复杂度。

　　继承机制有一个重要的缺陷，基类和派生类是强耦合关系，且破坏了封装，由此带来问题是：如果基类因为设计不当而进行修改，将影响所有派生类；另外，对于派生类的某个成员而言，你可能要花半天时间才能找到它究竟是在哪层实现，所以在设计过程中，一要尽量压缩继承的层数，二是坚持合成复用原则，能用合成就不用继承。
 
■ Login类的类视图