Object Oriented Programming (1)

本文部分内容节选自Effective C++ by Scott Meyers 和 UML面向对象设计基础 by Meilir Page-Jones。

 

1 封装
1．1概述

   软件是在20世纪40年代中以多个机器指令的集合体的形式首次出现的。后来进化到多行的汇编代码，此后不久，一种非常重要的结构出现了，这种结构将多行代码集中到一个程序单元里，并赋予一个惟一的名字，叫做子程序（或者过程）。子程序将封装（encapsulation）引入到软件中。将多行代码封装进入一种结构，比代码本身高一个级别。我们将没有经过封装的原始代码规定为0级封装，将封装的子程序的级别规定为1级封装。

   面向对象程序设计中，就是把客观事物封装成抽象的类，类是将相关的子程序以及其操作的数据集合在一起后形成的一个更高级别的结构体，因此，类处于2级封装。  
    一个标准的面向对象系统包含的类通常来自于四个主要领域：应用领域、商业领域、结构领域和基础领域。一个类的直接依附集（direct encumberance）是指这个类的直接引用集的大小。一个类的间接依附集（indirect encumberance）是指这个类的间接引用集的大小。在大部分面向对象的语言里，一个类C可以以下任何一种方式直接地引用另一个类D：

• 类C从类D中继承而来
• 类C中有类D的一个属性
• 类C中具有以类D作为输入参数的一个方法
• 类C中具有以类D的对象作为返回值的一个方法
• 类C中具有一个方法，这个方法包含了类D的一个局部变量

1．2 耦合
    在两个软件元素A和B之间，耦合（couple）意味着：

• 在A中进行了一些变化，那么为了保持全面的正确性，就需要对B进行同样的改变（或者至少要仔细的进行校验）。
• 或者为了保持正确性，需要在A和B中同时进行一些变化。

   耦合有显式和隐式之分，不过这两种形态也不是绝对的，它通常具有不同程度的显式性。另外还有方向性与非方向性，静态和动态之分，以下式一些常见的耦合类型： 

• 名称耦合
• 类型耦合
• 数值耦合
• 算法耦合
• 时序耦合

   到目前为止，我们看到的耦合等同于“一致”或者“相关”。但是耦合的另一个侧面是差异耦合，或者说否定耦合。比如类C是从类A和类B继承而来，那么A和B的不能有相同的名字，这就是一种名称差异耦合。    

   耦合是现代软件工程（software engineering）中的核心内容之一，一个没有封装边界(encapsulation boundary)的系统会存在两个问题：耦合泛滥和混淆了哪个是真正的耦合。为了提高系统的可维护性，有以下三个指导性原则：

• 通过将系统拆分为封装的元素使得整个耦合达到最小化。
• 将任何超越封装边界的的耦合最小化。
• 将封装边界内的内聚最大化。

   以下是面向对象系统中滥用耦合和常见情景：

• 无约束的继承（interitance）。
• C++友元函数（friend function）。
• 依赖与实现的偶然性。

1．3 内聚
    在结构化设计（SD）的十年间，模块聚合已经成为评价过程化模块质量的标准规范。在结构化程序设计中，Larry Constantine把模块聚合按照设计质量大约分成七级，从好到差分别是：功能组合、顺序组合、通信组合、过程组合、时序组合、逻辑组合和一致性组合。在面向对象程序设计中，类的内聚（class cohesion）是衡量位于一个类外部接口中的特性间相互关联的方法。一个差的内聚的类有一组不属于一个整体的特性。一个好的内聚的类具有这样的一组特性，这些特性通过类来实现抽象。有三种常见的内聚：混合事例型内聚、混合领域型内聚和混合角色型内聚。在这三种内聚中，混合事例型内聚是最不合理的，而混合角色型内聚相对来讲是比较合理的。

 

1．3．1 混合事例型内聚
    一个混合事例型内聚的类具有这样一些特性，对于类的对象来说这些特性是未被定义的。设想一个销售部门既有发放佣金的雇员，也有不发放佣金的雇员。Fred是具有佣金的雇员，而Mary是没有佣金的雇员。在采用面向对象方法来设计这个部门的应用系统时，有个SalesPerson类。根据以上给定条件，下面第一个调用中的第一个时有意义的，而第二个是没有意义的：
    Fred.issueCommission();
    Mary.issueCommission();

   我们也可以保持这个调用，并且将Mary的佣金设置为零。然而，这样说是一个谎言。Mary不具有值为零的佣金；她的佣金尚未定义。如果坚持这样做，那么SalesPerson类可能还需要一个名称为whetherCommission的布尔型变量，然后通过if语句进行判断。

   以上问题的本质是SalesPerson类具有混合事例型内聚，它将两种不同的雇员汇总到了一个类中。改造方法就是追加CommissionSalesPerson和NonCommissionSalesPerson两个子类，这两个类从SalesPerson继承而来。混合事例型内聚通常指出一个非精练或者非正确的类层次结构。正如我们所见到的一样，它也导致了违反类本身设计原则的一些粗糙代码（以附加的if语句形式表现）。

 

1．3．2 混合领域型内聚
    一个混合领域型内聚的类包含这样一个元素，这个元素是一个不同领域的非本征类（extrinsic）的直接依附集。非本征的定义如下：
    如果类A在不涉及任何类B概念的前提下能够完全得到充分的定义，那么对于类A来说，类B是非本征的。如果类B是捕获类A中固有的一些特性，那么对于类A来说是本征的。
    有很多混合领域型内聚的类子是不明显的，例如：在一个商业类库中有一个Real（实数）类，这个类具有一个arctan方法，（为了防止你学的三角学已经生锈， 解释一下，arctan是指反切函数，返回一个正切值是这个实数的角度。例如，1.0的反切值是45度）

 

1．3．3 混合角色型内聚
    一个具有混合角色型内聚的类C包含了这样一个元素，这个元素直接依附于和C同一领域的类的一个非本征类。与一个混合领域型内聚的类不同的是，一个混合角色型内聚的类并不是跨领域的。可是它包含了单一领域内的多个角色。
    设想一个涉及人和狗的例子，假设一个Person类具有一个numOfDogsOwned属性（一个人所拥有的狗的数量）。Person类中没有混合事例型内聚，但是，它有混合角色型内聚，因为Person和Dog之间是非本征的。混合角色型内聚最低限度地违反了内聚原则。可是，如果你注重Person类的可重用能力（比如要在一个没有Dog类的环境中重用Person类），那么就应该特别注意这个混合角色型内聚。