您好,登录后才能下订单哦!
虽然6月8日苹果WWDC大会之后,所有iOS开发者的眼光都被Swift 2和iOS 9吸引了,而iOS开发老语言Objective-C的受欢迎度却大不如从前。
虽然iOS开发出了新的swift语言,但是绝大部分老iOS开发从业者及新入门者,都没有放弃对Objective-C语言的使用和学习。所以苹果公司在今天也对Objective-C做了一些升级,以往这门语言的使用“局限”将不复存在。下面我们就一起来看下,今年Objective-C语言做了升级。
The Setup
iOS开发人员,对下面的代码一定再熟悉不过了,我们来重温一下吧:
@property(strong, nonatomic) NSArray *someViews;
这绝对符合Objective-C完美主义开发者的标准。对它表示的属性,不同人有不同观点。但是,其中仍然存在着一些难以察觉的缺陷。
是否可能返回nil?
除非有现成的文件,或开发者全程都在一旁,否则光凭看是无法获取信息的。
除了UIView之外还有什么?
还是那句话——不确定。也许答案是reflection? 或许问题可以改成:除了UIView,有可能出现UIView子类吗?
看样子会出现诸多转换(casting)
因为是一队列……东西,知道那东西是什么之后,经过cast后才能利用。
会弱化Swift代码和可读性
很遗憾,Swift语言支持泛型(generics)就意味着(Objective-C )只会以optional的AnyObject集合的形式出现。如此一来,开发者要使用该属性就必须在Swift和Objective-C之间进行转换。
NullabilityAnnotations
仅仅是一个属性就引发了这么多的担忧,还挺让人不安的。如果代码本身引发很多质疑,出现error的可能性就大大增加,更别提在广为熟知的Objective-C和语言新秀Swift之间相互调用(interoperability)了。现在Objective-C有了nullability annotations这个新功能,问题就简单多了,也可为编程剩下很多麻烦。
intent.
现在谈到API,(intent.)可能会,也可能不会返回nil,但不管怎样,终于不用花费数小时来排除漏洞了。以下有三个选项:
nullable — ThinkUIView?
nonnull — ThinkUIView
null_unspecified— Think UIView!
再回到实例属性。假设在运行时迭代这个属性来创建某个用户界面,在相应的位置应该有UIButton和UIView。
intent.大大提升了Objective-C,而且这个属性也不会在Swift里满满都是optional了。计算机的静态检验和Swift的可用性都得到了提升,最重要的是实现了API的intent通讯。
泛型
泛型的缺席一直以来是Objective-C开发者心头之痛,而在这门语言诞生32年之后,终于也支持泛型了。对于Objective-C来说,支持泛型将带来诸多改变,而且都是积极的改变。
现在可以定义属性,下指令给编译器来显示所有UIView:
@property(strong, nonatomic, nonnull) NSArray<UIView *> *someViews;
向属性强加UIView之外的东西时,编译器会报错。而且如今不用做大量头痛的转换(cast)了。
虽然Objective-C语言和swift语言看起来像iOS开发平台两个对立的语言,但Objective-C支持泛型确实对Swift而言也是好消息。Objective-C上次更新时,让Swift知道对象不应该是optional的,现在Swift还知道它们是UIViews,如此一来含混不清的AnyObject声明就不需要了。如今的Objective-C可以像C#、C++、Swift等语言一样通过<>括号来表示类型了。虽然通常是对协议表示一致性(conformance),但编译器知道何时、何地以及如何运用它们,且运用是经过推理的。
泛型的强大体现在整个Objective-C之中,可以用参数来表示扩展(extensions)、类别(categories)和类(classes),好处不仅仅体现在集合(collections)上,集合仅仅是结果而已。举个例子,看看NSDictionary,开发者肯定会偷着乐吧:
@interfaceNSDictionary<KeyType, ObjectType> (Lookup)
- (nullableObjectType)objectForKey:(KeyType)aKey;
@end
刚开始知道类型擦除(typeerasure)是为了这个的时候,我有点儿不满意,但考虑到老旧的Objective-C程序堆积在一起的问题,也就释怀了。类型擦除(type erasure)不但能实现二进制兼容,而且不改变Objective-C的执行时间。
KindOf Types
再次调用之前定义的属性,就会显示UIView。判断里面包含着views和buttons是再正常不过的事。
这种情况下,添加如下代码会发生什么呢?
[self.someViews[0]addTarget:self action:selector(aMethod:)forControlEvents:UIControlEventTouchUpInside];
编译器警告!
这是因为即便可以在这个属性里插入一个button,就算可以假设是个UIView,button也不一定没有经过转换。
新的KindOf特性能够轻松解决这种始料未及的情况。我们再回到实例属性上:
@property(strong, nonatomic, nonnull) NSArray<__kindof UIView *> *someViews;
实际上我们已经告诉编译器:属性及其集合会出现一些UIView。这样在类型协议里显示更多我们之前看不到的信息。其本质向下转型(downcasting)。
这意味着上述代码编译没什么问题,因为编译器知道集合里肯定会出现一个button。
虽然不喜欢Swift的人可能会刻意夸大Objective-C的优点,但如今两种语言实现了互相调用,这是Objective-C所有提升的最大价值所在。毋庸置疑,Objective-C的确比以往更加强大。
总结
虽然swift语言不断升级、变强,越来越多的iOS开发者开始使用swift语言了,但是还是有绝大部分的人在使用、学习swift的同时,仍在继续研究Objective-C语言,也还有很多初学者正在纠结到底是学swift还是Objective-C。相信,随着Objective-C的不断升级,将让大家对这两门语言的选择上,更加“欲摆不能”。不过这是好事,既然都好,那就让自己同时驾驭这两门语言吧。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。