objc@interface的设计哲学与设计技巧

迈不过友情╰ 2022-08-23 05:43 177阅读 0赞

学习objc时，尤其是先学过其他编程语言再来看objc时，总会对objc的**类**声明的关键字`interface`感到有点奇怪，在其它面向对象的语言中通常由`class`关键字来表示，而`interface`在java中表示的却大约相当于objc的`protocol`，这个关键字的区别究竟代表了objc语言的设计者怎样的思想呢，在objc类设计中需要注意哪些问题呢？接下来对这个问题进行一些思考和探究.

--------------------

# interface? #

先来段Wiki:

> In object-oriented programming, a protocol or interface is a common means for unrelated objects to communicate with each other. These are definitions of methods and values which the objects agree upon in order to cooperate.

接口约定了对象间交互的属性和方法，使得对象间无需了解对方就可以协作。  
说的洋气点就是`解耦`嘛，细心点也能发现Wiki中`interface`和`protocol`表示了相近的语义。  
引用我和项目组架构师讨论有关interface的问题时他的说法:

> interface就是一个object定义的可以被外界影响的方式

说着他指了下旁边桌子上放着的一把伞，说，这把伞我可以打开它，打开这个动作就是它的一个interface，桌子旁边还放着一个盒子，虽然它和伞都放在这张桌子上，但是它们之间永远不会互相影响，所以：

> interface只存在于能互相影响的两者间

--------------------

# @interface生成了class？ #

学习objc时最早接触的就是怎么写一个类了，从`.h`中写`@interface`声明类，再从`.m`中写`@implementation`实现方法，所以，objc中写一个`@interface`就相当于c++中写一个`class`。但这是真的么？

写个小test验证一下：  
有两个类，`Sark`和`Dark`，`Sark`类只有`.m`文件，其中只写`@implementation`；`Dark`类只有`.h`头文件，其中只写`@interface`，然后如下测试代码：

`NSClassFromString`方法调用了runtime方法，根据类名将加载进runtime的这个类找出来，没有这个类就回返回空(Nil)。  
结果是`sarkClass`存在，而`darkClass`为空，说明什么？是否说明其实`@implementation`才是真正的Class？  
进一步，不止能取到这个没有@interface的类，还可以正常调用方法（因为万能的runtime）

如下面的测试代码：

要是没有`@interface`的声明，类名，方法名都会报错说找不到，但是可以像下面一样绕一下：

其实，从`rewrite`后的objc代码可以发现，对于消息的发送，恰恰就是会被处理成类似上面的代码，使用字符串mapping出`Class`，`selctor`等再使用`objc_msgSend()`进行函数调用，如下面所示：

<table style="border-collapse: collapse; border-spacing: 0px; width: 925px; padding: 0px; margin: 0px;"> 
 <tbody> 
 <tr style="width: 925px; border-collapse: collapse; padding: 0px; margin: 0px;"> 
 <td style="padding: 0px; width: 925px; border-collapse: collapse; margin: 0px;"><pre style="overflow: auto; font-family: Menlo, 'Roboto Mono', Monaco, courier, monospace; font-size: 14px; color: rgb(82, 82, 82); padding: 1.2em 1.4em; line-height: 1.5em; margin-top: 0px; margin-bottom: 0px; background-color: rgb(248, 248, 248);">// 经过clang -rewrite-objc 命令重写后的代码
Sark *sark = ((id (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("Sark"), sel_registerName("new"));
((void (*)(id, SEL))(void *)objc_msgSend)((id)sark, sel_registerName("speak"));
</pre></td> 
 </tr> 
 </tbody> 
</table>

# 对比@interface和@implementation #

`@interface` 我们干过的事：

1.  继承
2.  声明协议
3.  定义实例变量（@interface后面加大括号那种）
4.  定义@property
5.  声明方法

`@implementation` 我们干过的和可以干的事：

1.  继承
2.  定义实例变量
3.  合成属性（@synthesize和@dynamic）
4.  实现方法（包括协议方法）

在`@implementation`干一些事情用的相对较少，但是是完全合法的，如这样用：

通过对比可以发现，**@interface对objc类结构的合成并无决定性作用**，加上**无决定性**是因为如果没有`@interface`会丢失一些类自省的原始数据，如属性列表和协议列表，但对于纯粹的对象消息发送并无影响。  
所以说，可以得出这么一个结论，**objc中@interface就是为了给调用者看的，是和调用者的一个protocol**，没错，就是**protocol**。

# 对比@interface和@protocol #

与其把`@implementation`扯进来不如对比下`@protocol`

我理解objc的`@interface`和`@protocal`间唯一的区别就是**是否和一个类型绑定**，这让我想起来`鸭子类型`(Duck typing), [wiki链接][wiki]

> “当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。”

Duck type在objc的体现无疑就是`@protocol`了，我们常用`id<XXXDelegate> delegate`的方式声明一个delegate，我们无需care这货到底是什么类型，我们只知道他能干什么就可以work了。同样的功能我也可以使用`XXXDelegate *delegate`的方式来定义，只不过这样的话这个类又需要耦合一个`XXXDelegate`类型，而这个delegate类是它原本并不需要关心的。

所以说，**`@interface`是`@protocol`的强类型升级版。**

举个`NSObject`的栗子最合适：

NSObject之所以成为NSObject，绝大多数都是`<NSObject>`协议定义的方法，实体类@interface定义的唯一一个变量`isa`指针，为了继承链和消息传递。 
除了`<NSObject>`协议外，NSObject还有很多Category来补充它的功能，其实仔细想想，Category更像protocol，一个`补充协议`，同样不能添加实例变量，但是和`@interface`一样需要与Class绑定。

进一步来讲，自从属性能自动合成变量之后，在头文件`@interface`中写大括号声明实例变量的情况越来越少（可以参见近几个版本iOS SDK中类头文件里这种写法几乎消失），因此，`@interface`和`@protocol`的差别进一步缩小。

--------------------

# 类与接口的设计原则 - 电视和遥控器 #

我喜欢将`Class`和`interface`的关系比喻成`电视+遥控器`，那么objc中的消息机制就可以理解成：  
**用户（caller）通过遥控器（interface）上的按钮（methods）发送红外线（message）来操纵电视（object）**  
所以，有没有遥控器，电视都在那儿，也就是说，有没有interface，class都是存在的，只是这种存在并没有意义，就好像这个电视没人会打开，没人会用，没人能看，一堆废铁摆在那儿。

![51530583tw1efdy7cw48wj20c108qjru.jpg][]

对比简洁的遥控器，一个拥有很多按钮的老式电视遥控器，我们经常会用到的按钮能有几个呢？  
![51530583tw1efe08u9hb7j208c0b4jrp.jpg][]

所以，在设计一个类的interface的时候，如同在设计遥控器应该有怎样功能的按钮，要从调用者的角度出发，区分边界，应该时刻有以下几点考虑：

1.  这个方法或属性真的属于这个类的职责么？（电视遥控器能遥控空调？）
2.  这个方法或属性真的必须放在`.h`中（而不是放在`.m`的类扩展中）么？
3.  调用者必须看文档才能知道这个类该如何使用么？（同一个业务需要调用者按顺序调用多次（而不是将这些细节隐藏，同时提供一个简洁的接口）才行）
4.  调用者是否可以很容易发现类内部的变量和实现方式？（脑补下电视里面一块电路板漏在外面半截- -）
5.  …

--------------------

# objc的@interface设计技巧Tips #

看过不少代码，从@interface设计上多少就能看出作者的水平，分享下我对于这个问题的一些拙见。

## 只暴露外部需要看到的 ##

比如，有如下一个类（这个类无意义，主要关注写法）：

<table style="border-collapse: collapse; border-spacing: 0px; width: 730px; padding: 0px; margin: 0px;"> 
 <tbody> 
 <tr style="width: 730px; border-collapse: collapse; padding: 0px; margin: 0px;"> 
 <td style="padding: 0px; width: 730px; border-collapse: collapse; margin: 0px;"><pre style="overflow: auto; font-family: Menlo, 'Roboto Mono', Monaco, courier, monospace; font-size: 14px; color: rgb(82, 82, 82); padding: 1.2em 1.4em; line-height: 1.5em; margin-top: 0px; margin-bottom: 0px; background-color: rgb(248, 248, 248);">// Sark.h
@interface SarkViewController : NSObject &lt;NSXMLParserDelegate /*1*/, NSCopying&gt; {
 
 NSString *_name; // 2
 IBOutlet UITextField *_nameTextField; // 2
}
@property (nonatomic, strong) NSXMLParser *parser; // 3
- (IBAction)nameChangedAction:(id)sender; // 4
@end
</pre></td> 
 </tr> 
 </tbody> 
</table>

这个interface出现的问题：

1. 类内部自己使用的协议，如`<NSXMLParserDelegate>`不应该在头文件@interface中声明，而应该在类扩展中声明；公开由外部调用的协议，如`<NSCopying>`则写在这儿是正确的。
2. `实例变量`和`IBOutlet`不应出现在这儿定义，这将类的内部实现暴露了出去，自从属性可以自动合成后，这里就更应该清净了。
3. 内部使用的属性对象不要暴露在外，应该移动到类扩展中。
4. 调用者对IBAction同样不需要关心，那么就不应该放在这儿。

## 合理分组子功能 ##

*  将相同功能的一组属性或方法写在一起

使用这个类或者对其进行修改时，一般都是从功能上找，所以把同一功能模块的一组属性或方法写在一块

*  纯操作方法的子功能（无需向类添加变量）使用`Category`分块
 *  在头文件中也可以使用`类扩展`将interface按功能分区

`Category`里不能添加实例变量，但是类扩展可以，一般都在`.m`中作为私有interface使用，同样在头文件里作为分区使用，如，ReactiveCocoa中的[RACStream.h][]

## 避免头文件污染 ##

首先，类实现内部.m文件中使用的其他interface应该在.m文件import，如果也写在header中就会造成对调用者的污染；当interface中出现其他`Class`或`protocol`时，可以使用前置声明`@class XXX`,`@protocol XXX`；当模块（一组类）内部间需要有一些定义（如常量、类型）而又不需要模块使用者知道时，使用一个内部头文件在模块中使用。

## 避免接口过度设计 ##

考虑调用者的使用方便是很必要的，过火了反而增加了复杂度：

<table style="border-collapse: collapse; border-spacing: 0px; width: 984px; padding: 0px; margin: 0px;"> 
 <tbody> 
 <tr style="width: 984px; border-collapse: collapse; padding: 0px; margin: 0px;"> 
 <td style="padding: 0px; width: 984px; border-collapse: collapse; margin: 0px;"><pre style="overflow: auto; font-family: Menlo, 'Roboto Mono', Monaco, courier, monospace; font-size: 14px; color: rgb(82, 82, 82); padding: 1.2em 1.4em; line-height: 1.5em; margin-top: 0px; margin-bottom: 0px; background-color: rgb(248, 248, 248);">@interface Sark : NSObject
- (instancetype)init;
- (instancetype)initWithName:(NSString *)name;
- (instancetype)initWithName:(NSString *)name sex:(NSString *)sex;
- (instancetype)initWithName:(NSString *)name sex:(NSString *)sex age:(NSInteger)age;
- (instancetype)initWithName:(NSString *)name sex:(NSString *)sex age:(NSInteger)age friends:(NSArray *)friends;
// 无数多个 //
@end
</pre></td> 
 </tr> 
 </tbody> 
</table>

提供了一组这样的方法，调用者可能只能用到其中的一个，那这样倒不如只留一个接口。

## 避免单例的滥用 ##

单例模式固然好用，但感觉有点过度，将接口设计成单例入口前需要考虑一下：

1.  这个类表达的含义真的只能有一个实例么？（如UIApplication）还是只是为了好调用而已？
2.  这个单例持有的内存一直存在
3.  是否能用类方法代替？
4.  这个单例对象是否能成为另一个单例对象的属性？如果是，应该作为属性

## 隐藏继承关系中的私有接口 ##

感谢`@像条狗在飞`在留言中提出的问题，问题大概可以总结为：当子类需要使用父类的一个私有属性（方法）时，需要把这个属性（方法）放到父类的header中，但暴露给子类的同时暴露给了外部调用者，如何解决?

我的方案是：建立一个`私有header`，使用`类扩展`定义父类需要暴露给子类的属性（方法），然后在各自的`.m`文件中引用，如：

有Father类和Son类，继承关系，可以考虑建一个如`FatherPrivate.h`的私有header：

同时在Father.m和Son.m中同时import这个私有header，这样，Father和Son内部对于定义的属性和方法都是透明的，而对外部是隐藏的（因为两个类的header中都没有import这个私有header）

--------------------

# 总结 #

*  `@implementation`合成了Class，而非`@interface`，`@interface`是`@protocol`的强类型升级版，它们和`Category`都表示了相近的含义
 *  我们应该善于面向接口编程，划清边界，将类的实现隐藏在调用者所见之外，使主调和被调者之间保持`最少知识原则`
 *  `@interface`本身就是最好的文档

--------------------

# References #

[http://en.m.wikipedia.org/wiki/Interface\_(object-oriented\_programming][http_en.m.wikipedia.org_wiki_Interface_object-oriented_programming])  
[http://zh.wikipedia.org/wiki/%E9%B8%AD%E5%AD%90%E7%B1%BB%E5%9E%8B][wiki]

--------------------

原创文章，转载请注明源地址，[blog.sunnyxx.com][]

[wiki]: http://zh.wikipedia.org/wiki/%E9%B8%AD%E5%AD%90%E7%B1%BB%E5%9E%8B
[51530583tw1efdy7cw48wj20c108qjru.jpg]: /images/20220721/ced0362c1adf42c4a5e1baedcf2f8986.png
[51530583tw1efe08u9hb7j208c0b4jrp.jpg]: /images/20220721/400ba3bdee464805bfccf5710db6fe4c.png
[RACStream.h]: https://github.com/ReactiveCocoa/ReactiveCocoa/blob/master/ReactiveCocoaFramework/ReactiveCocoa/RACStream.h
[http_en.m.wikipedia.org_wiki_Interface_object-oriented_programming]: http://en.m.wikipedia.org/wiki/Interface_%28object-oriented_programming
[blog.sunnyxx.com]: http://blog.sunnyxx.com/