Mattt Thompson：Cocoa之死
Posted Cocoa开发者社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Mattt Thompson：Cocoa之死相关的知识，希望对你有一定的参考价值。
Cocoa，作为一个包含大多数工作在Objective-C语言上必要的基本库的集合——比如Foundation、AppKit，和CoreData，已经成为了Objective-C的事实标准。而Cocoa Touch基本上就是用UIKit更换掉AppKit的Cocoa，而且它也经常用来和Cocoa放在一起，来指代在ios上的工作的系统框架。
对于我们多数人（开发者）来说，我们之所以构建基于苹果的平台之上的程序，是因为苹果的硬件和软件集成在一起的那种简单、优雅，和它优秀的性能表现。确实，在评价Cocoa的设计和功能上，从来都不缺少褒奖之词。
但是，在使用Swift几个月之后，我觉得Cocoa已经开始失去了它昔日的光环。我们都能看到Swift的流行最终会带来Objective-C的消失，但是Cocoa呢？
Swift在设计上包含了很多现代程序语言的特性，这些特性让用户能写出更安全高效的代码。不过，如果有人将Swift的出现仅仅看做是对编译器工具团队的消遣，也是情有可原的，因为我们很少能看到Swift的优秀特性在传统软件中的应用。
在刚开始的时候，使Swift能够以简单有效的方法和Objective-C进行互操作是很有战略意义的决定——同时在一定程度上也是必须的。这样做将允许团队中愿意冒险的工程师，以一种低风险的方式将Swift加入到已经在运行的代码中去，这对于一个新语言的发展和大面积推广是很重要的。但是对于专注于源文件映射和API 审核（source mapping and API auditing）方面工作的人来说，他们可能会争论说Cocoa已经成为负担（译者：因为这些往往是跟语言特性相关的）。
如果我们要基于Swift标准库构建一个新的Foundation框架呢？我们会做出什么不同的事情，还有我们如何从过去的错误中吸取教训？讨论这些对于NSHipster—一个基于对Objective-C和Cocoa的喜好而建立的网站来说，可能是一个奇怪的话题，但却是一个值得探索的课题。
所以为了告别这对苹果开发者来说具有历史性意义的一年，让我们花点时间来看看未来会有那些事情可能会发生。
我们所有的生产力都要归功于标准库。
一个设计良好的标准库不仅提供了最常用的编程结构的实现，同时它们也用一种良好的方式澄清了那些结构的概念。当一个标准库与已存在的（甚至是内部的）约定背道而驰时，事情往往就开始变得糟糕了。
例如，NSURLComponents 遵从文档 RFC 3986，其功能和使用方法在这个文档中有详尽说明。这样不仅使用者在使用这个API的过程中能够优雅而正确的理解术语的含义，就算是新学习这个API的人，只要他们熟悉RFC3986文档，就可以轻易的开始工作。（另外，相关的文档的编写将会变得多么简单，只要写“RTFM”然后挂一个超链接到这个文档就好了）
标准库就应该实现标准。
当我们说技术变得很直观，通常意思是说他们是很常见的技术。当我们要构建任何新标准库时，都应该建立在IETF、ISO和其它地方定义的标准之上。
基于这个断言，让我们用一些实际的例子看看有哪些Cocoa已经实现了的，Swift标准库可以改进的地方。
数值计算
NSNumber的存在仅仅是作为对integer, float, double, 和 boolean等基本变量的包装。在Swift中则不需要考虑到这点，所以在Swift中没有这样一种结构。
Swift的标准库聪明地将顶级函数、操作符和类型层级进行组合，通过这样的组合在构建数值基本变量上做了非常卓越的工作。（而且额外的在十进制的基础上增加了二进制，八进制和十六进制）。目前对于 Swift标准库特性的抱怨貌似不多，那么我来说下接下来那些应该加进去的特性。
一个合适的NSDecimalNumber的替代。根据Swift的文档，Double有64位，但是NSDecimalNumber可以表示任何可以用（a乘以10的n次方）表示的数，其中a是一个最长为38位的十进制整形变量，n是从-128到127的整形变量。同时，这里提供了一些关于在Swift环境下使用NSDecimalNumber的必要的补充。
复杂数字的支持，例如这里描述的。
简单的生成随机数的本地方法，这里举了几个相似的例子。
利用重载来提供一个可以用来执行一个或者多个数值计算的统一接口的方法，例如这里描述的。
基于Playground的一个内建的数学符号框架，比如Euler，可以用来作为一个优雅的教学工具。
字符串处理
字符串的危险在于他们可以编码如此多不同类型的信息，像之前写的一篇文章：
字符串可能是在计算领域最万能的数据类型。它通过符号传输，可以用来编码数值，关联键值对，表示资源路径，表示语言学内容，还可以格式化信息。
尽管如此，NSString可能太过通用了。尽管它在处理Unicode方面特别出色，但是整个API背负了因字符串作为路径而带来的多样化负担。stringByAppendingPathComponent：还有和它相同的一族API都非常实用，但是这种实用来源于对字符串作为URL的不合理使用。
这其中很多都是因为写@"this"（一个字符串常量）要比写[NSURL URLWithString:@"that"]（一个构造函数）要简单方便的多得多。不过，在Swift中，随着Swift的常量可改变协议的出现，使用字符串构建URL和Path会变得非常简单。
在Swift设计中有很多非常明智的决定，其中之一便是内部使用编码独立的Unicode字符，和暴露的“视图”用来指定编码类型。
使用utf-8编码的字符单元集合 (使用 utf8 属性访问)
使用utf-16编码的字符单元集合 (使用 utf16 属性访问)
21位的Unicode编码值的集合，和utf-32编码格式相同 (使用 utf16 属性访问)
当然对于Swift的String也有一些抱怨，其中之一就是有很多功能被隐藏了，就像某些功能隐藏在顶级函数之下一样。多数开发者被训练成在编辑器中打出点（ . ）之后，等待IDE代码提示像“count”这样的函数；而不太可能去查阅像countElements这样的顶级函数。(再次提示，就像在这篇文章里描述的一样，这个情况可以通过Xcode或者Swift本身允许在函数中自动连接隐式和显式的self来解决)
URI, URL, and URN
理想的URL实现应该是NSURLComponents的值型（value-type，也就是struct）实现，如果这样做，以上我们提及的在NSString中路径相关的API都将被取代。这里是一些与此相关的东西。一个清晰的基于RFC 4395的URI机制的实现，能够减轻现在存在于NSURL中的关于文件URL（file://）的多义合并。一个好的基于RFC 2141的URN的实现可以让开发者理解什么是URN，以及对理清URI、URL和URN相互间的关系带来帮助。（这全是举一反三的能力）
数据结构
Swift中的数据类型，从泛型到序列再到集合，所有的一切都很美。在对Array和Dictionary常量的语法糖的运用，和它们背后更耐人寻味的标准库思想之间达到了很好的平衡。
在这些强大的基本数据结构基础之上，就算一个大学计算机科学课程上的学生，都已经可以轻易地构建可用于生产环境的数据结构。在此之上再借助维基百科，利用一个清闲的下午，差不多任何一个人都可以完成这个工作，或者说至少可以差不多完成。
关于复杂数据类型，如果Swift的基本库要提供这些一大堆的数据结构（例如，树，链表，队列／堆栈）的实现的话，我才笑掉大牙哩。但是有一个我认为是例外：集合（Set），这个可以有。
在Foundation框架中有的三种集合类型，分别是NSArray, NSDictionary, and NSSet (还有他们的mutable版本)。在这三个之中，只有Set现在在Swift中还没有。作为一个基本的数据结构，他们在很多用例场景中都会被用到。具体到对于Swift来说，Set是可以解决很多不常遇到的问题的——参考RawOptionSetType.
Nate Cook 构建了一个漂亮而且完整的Set的实现，仅供参考。
日期和时间
日历相关的功能是Cocoa中最古老并且最健壮的特性之一。在其他语言中，日期和时间相关的编程总是会带来恐惧，但是当你使用NSDate和NSCalendar时就完全不会有这种感觉。然而，让人抓狂的是它们却有点难用而且不能扩展。
为了做一些日历的计算工作，比如想获取从今天开始算一整个月后的日期，人们可能会用NSCalendar和NSDateComponents，至少，这是正确的方法，大多数的开发者可能还在用dateWithTimeIntervalSinceNow:，放一个不变的秒数硬编码在那里。不幸的是，仅仅提供正确的方法来对于API来说远远不够的，API需要提供一个更易于使用的方法。
NSCalendar还有另外一个缺点（尽管非常小），就是它不允许新日历的加入。对于那些非要在法国共和历上稍加改动的人来说，这是非常讨厌的。
幸运的是，这些问题都可以使用Swift中的新的特性优雅地解决掉。这可能会耗费一些时间，但是一个基于范型的日历系统真的非常了不起。如果有人想中这个方面挑战我，这里是一些想法
数据交换格式
在Objective-C中，很长时间之后（iOS5/ OS X Lion!）才有了对于JSON格式的操作的标准方法，这着实非常令人惊讶。JSON已经是在web service中最流行的数据交换格式，而那些想要在iOS中使用JSON的开发者被迫要从少数几个彼此互不兼容的第三方库中做出选择。
然而，现在我们又碰到了这样的问题，NSJSONSerialization在Swift中使用的体验太垃圾了，以至于我们要再次去从第三方库中做出选择。
|
1
以上是关于Mattt Thompson：Cocoa之死的主要内容，如果未能解决你的问题，请参考以下文章 |