英文原版：A Year’s Worth of Opinions about Objective-C

我在一年前因需要将RedPhone项目从Android移植到iOS而首次接触Objective-C。大约一个月前我负责的部分（后端：声音，网络， 加密部分）已经完成。我们正等着外部的安全审查，同时在内部继续完成UI工作的过程中并未发现任何后端的bug(言外之意开发质量高)。在 RedPhone最终发布后，我对于这次工作中哪些做错了，基于android和ios的代码都有哪些不同等等做了讨论。今天想探讨一下去年过程中关于 Objective-C的一些体验。

一年前我从未接触过Objective-C.（一行代码也没看过）我是名C#开发。现在我认为自己是名中级Objective-C开发：

虽然还有很多知识上的漏洞但我在现在使用这门语言已算是得心应手。比如，大家都知道不能把nil赋给数组和其他的集合类型，但就在上周我还不知道可以直接插入NSNull来实现。当然了，我只是假设大家只是不会把nils赋给某个集合。（意味着大部分人也不知道这个workaround）

当我讨论语言时，我听起来会倾向于比较挑剔，所以请记住这篇文章不是指控Objective-C无法有效的处理问题。这篇文章是关于我使用Objective-C的经验，它和其他语言不同的地方，以及我遇到的问题。这是我的观点，因为编程领域充满了关于哪种语言更好的完全对立的观点（e.g. 动态 vs 静态类型编程语言），你可以相信，这仅仅是以一对多。一个相关的引用：

仅有两种语言：一种是大家抱怨的，另一种是没人使用的。 —— Bjarne Stroustrup

概述

Object-C是C语言的超集，所以很自然的让我注意的第一件事是它哪里和C不同。基本上你在以Obj-C风格写代码时唯一做的类似C的事情(C-ish stuff)是使用头文件和使用前进行类型声明。

奇怪的是，Objective-C使我想起的更多的不是C而是Visual Basic 6。至少，是在我每日使用所遇到的问题上。Obj-C和VB6两者都 喜欢让程序保持 运行下去(即使出错了，译者注)。这是不是个奇怪的现象？程序可能会错过打破当前状态的问题。另外，两种语言都使用引用计数来清理内存，这会随着你的深入造成更多内存泄露。永远警惕引入循环引用。最后，两者都没有泛型类型。把这些话都直直的装入你的脑子里，否则你接下来的日子会很难过。

还有另一件Obj-C与VB的包袱，例如，在Objective-C中许多对象有 “core foundation”、 “new style” “NeXTSTEP”的形式，而自动引用计数技术早在两年前就已渗透到整个社区了，当然了，还有C的子集。所以，大多数情况下我们可以忽略这些历史包袱，但它们的出现，我并不是暗示说Obj-C与VB是相同的编程语言，它们有很大不同，首先，语法就有很大的不同。

语法

Objective-c的语法很特别。传递一个消息（如调用个方法），你需要用方括号把接收消息的对象以及消息括起来。消息由参数名和值组成，因此不能像 list.Insert("test", 0)这样写，而是这样 [mutableArray insertObject:@"test" atIndex:0]。

当调用方法时给每个参数取个名字可以使代码非常清晰，但是不可避免的增加了代码量。总的来说这是件好事。另一方面，我认为让方括号在目标对象之前开着，而 不是在目标对象之后（像Java, C#, C++)是个错误。这使你更难确定你在一个表达式的位置，并且使一个简单的序列变成了深层嵌套。扩展一个表达式是个反复的事情，因为你必须回到行首添加 [。 当前输入 ] 时XCode会尝试猜测 [ 的相对位置，但是它老是搞错以致变得更糟。

幸运地是，Objective-c有些语法糖可以让你在一般情况下摆脱嵌套。点记法 可以让你重写简单的getter表达式，如[a value] 重写为 a.value。setter, 数组索引，字典查找也有类似的语法糖。他们确实为减少冗长的代码创造了奇迹。

Objective-c 也有容器了， 这个是关于这门语言我真的很喜欢的第一件事。你想要个字典？只需要输入@{key:val,key2:val2,...}， 没有自动包装，因此你不得不在每一处添加@符号，像@{@"a":@1,@"b":@2,...}， 但是相比于人们过去不得不做的（大量地NSNumber numberWithInt:，以null结束的NSArray arrayWithObjectsfor:值，another key值，最后不幸中的万幸NSDictionary dictionaryWithObjects:forKeys:）这只是很小的代价。

我没有预料到Object-C会有匿名函数的功能，但是它确实有（它们叫做块）。块语法因为缺乏推理类型语法，所以你不得不写^(int x){return x*x;}用来替代 x=>x*x，但是确实足够简明可以被使用。

另外一个对于Object-C语法来说的必要点就是前缀使用“+”和“-”用于区分静态方法和实例方法(错误的...信息)。你将会很快的习惯它，虽然它的这些差别看起来有些滑稽。

类型系统

如果让我说一句我恨Objective-C的地方，那一定就是类型系统了。它很难表示出很多有用的类型(例如没有泛型)并且实际上它也不能检查你的工作(甚至在运行时)。虽然它在感觉上很动态，但是我更喜欢静态的强类型。

一开始，Objective-C没有null(但是C语言有，虽然你不常用)。替代的，Objective-C有nil，它很像null除了当你不小心在 程序里使用它的时候它不会使程序停止。发给nil的消息不会抛出异常，它仅仅只返回了一个nil并且实际上不作任何的评估。

我是真的真的不喜欢nil. 例如，假设你写了像构造函数的方法，它有一个叫SuperImportantSecurityChecker的参数。
你坚持参数不是nil，因为对不合逻辑的不被执行进行安全检查是很糟糕的。
你 也可以写一个测试，故意导致安全失败，并且检查下确实是失败了。你做的很好，因为你忘记了用SuperImportantSecurityChecker 参数的值初始化SuperImportantSecurityChecker了。像这样的错误会几年都不会被发现，这多亏了nil。

另一个例子，当程序已经出错了，但是会继续运行，令人吃惊的竟然是缺少运行时类型检查。例如，如果你写NSMutableArray* v = [NSArray array]，Objective-C会高兴的将你的可变数组的指针指向一个不可变的数组（你以前甚至没有看到编译报警，因为NSArray.array 返回id, 现在它返回 instancetype)。当你尝试去调用给“可变”数组添加对象的方法时，程序会崩溃，错误提示为“selector not found”。这个并不像不可期的nil那样糟糕，nil会悄悄地丢弃要添加的项而不是崩溃，但是查找这些错误是很恼人的。

当在块上工作时缺 少运行时检查是非常恶心的，因为语言允许你过度自由的指定输入类型。这种写法看起来多么诱人,[array enumerateObjectsUsingBlock:^(NSNumber* obj, NSUInteger index, BOOL *stop) { ... }];，根据你的期望，thatobjshould通常是一个数字而不是generalid，但是有时候你会搞砸它并且不得不追踪问题所在。我已经采取了 在大多数块开始前加一行strewingassert([obj isKindOfClass:[WhateverType class]])来先发制人的捕捉这些错误。

另一个值得注意的Objective-C会默默舍弃的是，如果你忘记了特定的编译选项。你或许已经知道不指定“- Objc"会导致分类方法在运行时不被接受，尽管不会在编译时被发现，但是你知道不包含-fobjc-arc-exceptions”会导致有异常抛出时ARC不能正确的进行清理吗？根据约定 强烈支持你不要捕获异常是合理的，并且速度好处显然不小，但是，苹果让他们的语言的默认执行不正确的行为着实让我受宠若惊。

基本上，我时常感觉Objective-C的类型系统是在挑战我。我也尝试写一个安全的voip应用来保护你免受你的压迫性的政府，但是我在用的语 言实际上被设计成升级微不足道的错误来折中，而不是立马崩溃。我觉得，我将从不会犯低级错误，因此没有人会死，对吗？这是完美的。或者有些人受虐待。。。 我也许也会检查它十多次。。。

XCode

语言的开发环境，是很影响你对该语言的感受的。开发Objective-C程序可以选择苹果公司的XCode工具，我个人比较习惯于使用XCode。此外 还可以选择JetBrain的AppCode开发环境来开发，虽然这个工具是收费的，但说实话我不是很喜欢，没用多久就丢弃了。

如果我给XCode评个分的话，满分5分我给3分，算是中规中矩吧。XCode有许多细节做得很棒，比如， 这个fantastic  ，它会高亮显示匹配的花括号（闪烁黄色高亮），还有方法自动补全之后，有行内气泡提示，这也非常好用。不过也有许多不足之处。

奇怪的是，我主要抱怨的是项目文件的格式。我发誓，它设计就是为了引起合并冲突。我不知道是否UUID与各个条目、重复信息，或者每行多种信息相关。。。但我不记得最后一次我合并，而没有手动修复&*(&ing项目文件。

有趣的是，对项目经常性的崩溃有些本末倒置。修复项目最快的方法是恢复它，然后通过把对应的文件夹拖进项目中重建组，来修复包含源代码的组（这么做 是有效果的，因为源码文件合并是正常的）。这个规律的重建操作保持你的组与文件系统同步，因此你的项目不会在像github一样的外部环境中看起来一团 糟。多么“方便”啊。

我使用XCode的下一个问题是自动补全。它并不擅长这个。特别是当你在上面已经有了写了一半的代码，在你编辑时总是可以保证看到部分结果。这会诱使你认为基本的方法不存在，因为你正在盯着一个不包括它们的补全列表。XCode自动补全的另一个情况是当你使用点语法时明显不好：它基本没工作过。输入一个空格，你得到很多的结果，包括读取器，但对应输入一个点，你将可能看不到任何结果。令人沮丧。

我对XCode的最后一个抱怨，也是值得提一下的，是有限的重构功能。在重命名变量和一些其他东西时，会受限制，而且也没什么效果。这真的很慢（我 见过花费几分钟的情况），另一半情况就是XCode崩溃。老实说，如果你想要做重构的话，你应该仅仅安装AppCode。要么用那个，要么习惯忍受 find+replace。