csdn移动将持续为您优选移动开发的精华内容,共同探讨移动开发的技术热点话题,涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面。如果您想投稿、参与内容翻译工作,或寻求近匠报道,请发送邮件至tangxy#csdn.net(请把#改成@)。
当众人的目光聚焦在wwdc 2015新推出的swift 2和ios 9上时,我的思绪却飘回到办公室书架上。多年前,初入ios开发时买的objective-c指导书直至今日还静静地躺在那里,求知若渴地翻动着书页的场景历历在目,心中所想的不是objective-c的优点,却是它的局限——如今这位老友旧貌换新颜,以往的“局限”不复存在。2015年objective-c都有哪些提升?这篇文章即将揭晓答案。
the setup
下面的代码你们一定再熟悉不过了,我们来重温一下吧:
@property (strong, nonatomic) nsarray *someviews;
这绝对符合objective-c完美主义开发者的标准。对它表示的属性,不同人有不同观点。但是,其中仍然存在着一些难以察觉的缺陷。
是否可能返回nil?
除非有现成的文件,或开发者全程都在一旁,否则光凭看是无法获取信息的。
除了uiview之外还有什么?
还是那句话——不确定。也许答案是reflection? 或许问题可以改成:除了uiview,有可能出现uiview子类吗?
看样子会出现诸多转换(casting)
因为是一队列……东西,知道那东西是什么之后,经过cast后才能利用。
会弱化swift代码和可读性
很遗憾,swift支持泛型(generics)就意味着(objective-c )只会以optional的anyobject**的形式出现。如此一来,开发者要使用该属性就必须在swift和objective-c之间进行转换。
nullability annotations
单单一个属性就引发了这么多担忧,还挺让人不安的。如果代码本身引发很多质疑,出现error的可能性就大大增加,更别提在广为熟知的objective-c和语言新秀swift之间相互调用(interoperability)了。现在有了nullability annotations——我最爱的objective-c新功能之一,问题就简单多了,编程也会省下很多麻烦。
intent.
现在谈到api,(intent.)可能会,也可能不会返回nil。简而言之,终于不用花费数小时来排除漏洞了。以下有三个选项:
nullable — think uiview? nonnull — think uiview null_unspecified — think uiview!
再回到实例属性。假设在运行时迭代这个属性来创建某个用户界面,在相应的位置应该有uibutton和uiview。
但是,天哪!——不论怎么样它们也不应该是nil啊。现在出现如下的信息:
@property (strong, nonatomic, nonnull) nsarray *someviews;
intent.大大提升了objective-c,而且这个属性也不会在swift里满满都是optional了。
开发者看看代码就知道有没有nil pointer了,太棒了!
计算机的静态检验和swift的可用性都得到了提升,最重要的是实现了api的intent通讯。
泛型
……objective-c开发者们举国欢庆。呜呼,泛型的恩泽终于笼罩大地,这无疑是那些开发者勇士们的功劳。
如果把cocoa touch比作孩子们的睡前故事,那么objective-c就好比是主演,故事书肯定是以上面那段话结尾的。泛型的缺席一直以来是objective-c开发者心头之痛,而诞生32年之后,objective-c终于也支持泛型了。2015 wwdc上swift 2成为了镁光灯下的宠儿,而objective-c这一巨大的跨越却被忽视了,实在委屈。支持泛型将带来诸多改变,而且都是积极的改变。
现在可以定义属性,下指令给编译器来显示所有uiview:
@property (strong, nonatomic, nonnull) nsarray
向属性强加uiview之外的东西时,编译器会报错。而且如今不用做大量头痛的转换(cast)了。
objective-c支持泛型对swift而言也是好消息。上次更新时,我们让swift知道对象不应该是optional的,现在swift还知道它们是uiviews,如此一来含混不清的anyobject声明就不需要了。如今的objective-c可以像c#、c 、swift等语言一样通过<>括号来表示类型了。虽然通常是对协议表示一致性(conformance),但编译器知道何时、何地以及如何运用它们,且运用是经过推理的。
再进一步,可以用参数来表示扩展(extensions)、类别(categories)和类(classes),好处不仅仅体现在**(collections)上。泛型的强大体现在整个objective-c之中,**仅仅是结果而已。举个例子,看看nsdictionary,开发者肯定会偷着乐吧:
@interface nsdictionary
刚开始知道类型擦除(type erasure)是为了这个的时候,我有点儿不满意,但考虑到老旧的objective-c程序堆积在一起的问题,也就释怀了。
类型擦除(type erasure)不但能实现二进制兼容,而且不改变objective-c的执行时间。所以亲爱的开发者们,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的确比以往更加强大。
总结
对我来说,objective-c是开发生涯中的初恋,相比其他语言,它是那么与众不同——直到今天都是如此,它的好、它的坏都让我欲罢不能。虽然如今swift正以迅雷不及掩耳之势征服着我的心,我还是希望objective-c陪伴在身边。
objective-c的提升能够帮助开发者写出更好的代码,这是好事。而且这些优势已经在foundation中随处可见了。
(翻译/张新慧 审校/唐小引)
文章来源: medium
第一时间掌握最新移动开发相关信息和技术,请关注mobilehub公众微信号(id: mobilehub)。
本文来自投稿,不代表商川网立场,如若转载,请注明出处:http://www.sclgvs.com/peixun/29991.html
尊龙凯时网站的版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请联系尊龙凯时网站举报,一经查实,本站将立刻删除。