ASP.NET入门随想六之大航海家

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

　　笨人是无法理解一个塞满各种复杂功能的对象，所以类的第一设计原则是单一，对应问题空间中的一个概念。如果所对应的概念包含其它概念，却为整体/ 部分关系，称之为"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类的类视图

查看本文来源