第九条 以"类族模式"隐藏实现细节

2017/7/4 posted in  第二章 对象,消息,运行期

"类族"(class cluster,也叫类簇)是一种很有用的模式(pattern),可以隐藏"抽象基类"(abstract base class)背后的实现细节.

Objective-C的系统框架中普遍使用此模式。比如,iOS的用户界面框架(user interface framework) UIKit中就有一个名为UIButton的类。想创建按钮,需
要调用下面这个“类方法”(class method):

+ (UIButton*)buttonWithType:(UIButtonType)type;

该方法所返回的对象,其类型取决于传入的按钮类型(button type)。然而,不管返回什么类型的对象,它们都继承自同一个基类:UIButton。这么做的意义在于:UIButton类的使用者无须关心创建出来的按钮具体属于哪个子类,也不用考虑按钮的绘制方式等实现细节。使用者只需明白如何创建按钮,如何设置像“标题”(title)这样的属性,如何增加触摸动作的目标对象等问题就好。

我们使用"类簇",是为了可以灵活应对多个类,将它们的实现细节隐藏在抽象基类后面,以保持接口简洁。用户无须自己创建子类实例,只需调用基类方法来创建即可。

创建类簇

我们现在来看一个样例学习创建类簇.假设有一个处理雇员的类,每个雇员都有“名字”和
“薪水”这两个属性,管理者可以命令其执行日常工作。但是,各种雇员的工作内容却不同。经理在带领雇员做项目时,无须关心每个人如何完成其工作,仅需指示其开工即可。

首先要定义抽象类:

typedef NS_ENUM(NSUInteger, EOCEmployeeType) {
    EOCEmployeeTypeDeveloper,
    EOCEmployeeTypeDesigner,
    EOCEmployeeTypeFinance,
};

@interface EOCEmployee : NSObject

@property (copy) NSString *name;
@property NSUInteger salary;

// Helper for creating Employee objects
+ (EOCEmployee*)employeeWithType:(EOCEmployeeType)type;
//Make Employees do their respective day1s work
- (void)doADaysWork;

@end

@implementation EOCEmployee
+ (EOCEmployee*)employeeWithType:(EOCEmployeeType)type {
    switch (type) {
        case EOCEmployeeTypeDeveloper:
            return [EOCEmployeeDeveloper new];
            break;
        case EOCEmployeeTypeDesigner:
            return (EOCEmployeeDesigner new];
            break;
        case EOCEmployeeTypeFinance:
            return (EOCEmployeeFinance new];
            break;
        }
}
-(void)doADaysWork {
    // Subclasses implement this.
}

@end 

每个"实体子类"(concrete subclass) 都从基类继承而来。例如:


@interface EOCEmployeeDeveloper : EOCEmployee
@end

@implementation EOCEmployeeDeveloper

-(void)doADaysWork {    
    [self writeCode];
}

@end

在本例中,基类实现了一个“类方法”,该方法根据待创建的雇员类别分配好对应的雇员类实例。这种“工厂模式”(Factory pattern)是创建类族的办法之一。

OC这门语言没有办法致命某个基类是"抽象的"(abstract).于是,开发者通常会在文档中写明类的用法。这种情况下,基类接口一般都没有名为init的成员方法,这暗
示该类的实例也许不应该由用户直接创建。还有一种办法可以确保用户不会使用基类实例,
那就是在基类的doADaysWork方法中拋出异常。然而这种做法相当极端,很少有人用。

如果对象所属的类位于某个类族中,那么在査询其类型信息(introspection)时就要当心了(参见第14条)。你可能觉得自己创建了某个类的实例,然而实际上创建的却是其子类的实例。在 Employee 这个例子中,[employee isMemberOfClass:[EOCEmployee class]]似乎会返回YES,但实际上返回的却是NO,因为employee并非Employee类的实例,而是其某个子类的实例。

Cocoa里的类簇

系统框架中有许多类族。大部分collection类都是某个类簇中的抽象基类,例如NSArray与其可变版本NSMutableArray。这样看来,实际上有两个抽象基类,一个用于不可变数组,另一个用于可变数组。尽管具备公共接口的类有两个,但仍然可以合起来算作一个类族(传统类簇模式中,通常只有一个类具备"公共接口",就是抽象基类)。不可变的类定义了对所有数组都通用的方法,而可变的类则定义了那些只适用于可变数组的方法。两个类共属同一类族,这意味着二者在实现各自类型的数组时可以共用实现代码,此外,还能够把可变数组复制为不可变数组,反之亦然。

像NSArray这样的类的背后其实是个类族(对于大部分collection类而言都是这样),明白这一点很重要,否则就可能会写出下面这种代码:


id maybeAnArray = /* ••• */;
if ([maybeAnArray class) == [NSArray class]) {
"Will never be hit
}

你要是知道NSArray是个类族,那就会明白上述代码错在哪里:其中的if语句永远不可能为真。[maybeAnArray class]所返回的类绝不可能是NSArray类本身,因为由NSArray的初始化方法所返回的那个实例其类型是隐藏在类族公共接口(public facade)后面的某个内部类型(internal type)。

不过,仍然有办法可以判断出某个实例所属的类是否位于类族之中。我们不用刚才那种写法,而是改用类型信息查询方法(introspectionmethod)。本书第14条解释了这些方法的用法。若想判断某对象是否位于类族中,不要直接检测两个“类对象”是否等同,而应该采用下列代码

id maybeAnArray = /* ••• */;
if ([maybeAnArray isKindOfClass:[NSArray class])) {
    "Will be hit"
}

我们经常需要向类族中新增实体子类,不过这么做的时候得留心。在Employee这个例子中,若是没有“工厂方法”(factory method)的源代码,那就无法向其中新增雇员类别了。然而对于Cocoa中NSArray这样的类族来说,还是有办法新增子类的,但是需要遵守几条规则。这几条规则如下。

  • 子类应该继承自类族中的抽象基类。
    若要编写NSArray类族的子类,则需令其继承自不可变数组的基类或可变数组的基类。

  • 子类应该定义自己的数据存储方式。
    开发者编写NSArray子类时,经常在这个问题上受阻。子类必须用一个实例变量来存放数组中的对象。这似乎与大家预想的不同,我们以为NSArray自己肯定会保存那些对象,所以在子类中就无须再存一份了。但是大家要记住,NSArray本身只不过是包在其他隐藏对象外面的壳,它仅仅定义了所有数组都需具备的一些接口。对于这个自定义的数组子类来说,可以用NSArray来保存其实例

  • 子类应当覆写超类文档中指明需要覆写的方法。
    在每个抽象基类中,都有一些子类必须覆写的方法。比如说,想要编写NSArray的子
    类,就需要实现count“objectAtlndex:”方法。像lastObject这种方法则无须实现,因为基类可以根据前两个方法实现出这个方法。

在类族中实现子类时所需遵循的规范一般都会定义于基类的文档之中,编码前应该先看看.

要点

  • 类族模式可以把实现细节隐藏在一套简单的公共接口后面。
  • 系统框架中经常使用类族。
  • 从类族的公共抽象基类中继承子类时要当心,若有开发文档,则应首先阅读。