原文地址：https://www.bignerdranch.com/blog/should-i-use-a-property-or-an-instance-variable/
如原作者发现有侵权行为可责令我在24小时之内删除，前提是你能看到的话。
当苹果发布Swift时，我听到一些人说:“Hurray!现在我不用学OC就能当一个iOS程序猿了!”我有三句话想送给这些人:
- 如果你想成为一个iOS程序猿,你仍然需要了解OC.
- OC要比Swift更好学.
- 只要你了解OC,学习Swift是件很容易的事.
在我往下说之前，让我将这段作为对Swift爱的告白.Swift的语法是很友好的.Swift编译器会为我们捕获很多的error;我确信当每个人都用Swift编程的时候，app的可靠性将会有显著地提升.Swift的枚举结构是很优美的.Swift是我们迈向iOS和Mac OS X生态系统的关键一步.但是...
如果你想成为一个iOS程序猿,你仍然需要了解OC
你不能用Swift做所有的事.例如,如果你想在你的应用中使用一个C++的库,你仍将需要用OC来操纵C++对象.Swift可以调用C语言的函数,但是我认为如果你的应用中有大量的C语言函数和类型变量,你还是还想用OC来编程的。
在论坛中都用OC交流.在StackOverFlow上有实用性的代码段和iOS开发者的博客随处可见.过去六年中，我在和其他程序员探讨Cocoa Touch类库工作原理的时候,都是用OC来交流的.如果你读不懂OC代码,你讲无法收获这笔知识的财富。
苹果的框架使用OC写的.有时当你遇到一个bug的时候(能力有限,原文写的太拗口,不会直译,所以一图胜千言),就是如下图所示的场景:
程序崩溃.png
这个时候打印出来很多类似于_NSPlaceholderArray这种苹果的私有变量和方法,如果你想看懂并理解控制台打印的错误信息,你就需要理解OC.
OC稳定易测试.Swift看起来很好,但是这门语言还在不断发展中(现在好像Swift3.0要发布了，作者的分析还是比较准确的)，而且它的编译器还不够成熟.如果让我赌注今年的app开发语言，我会使用OC(这篇文章是去年11月发表的,回顾2015,好像使用Swift的还是不多,但这个趋势确实是无法阻挡的,现在让我赌的话,我赌明年将会有一半的公司开始尝试Swift,反正也没有赌注是不).
OC要比Swift更好学
C的确是一门短小精悍的语言,而OC是C精简的扩展.Swift有很多OC所没有的规则.(作者:我是一位导师,我一直都在尽力找方法来向学生们阐述Optional这种数据类型的正确使用方法以及使用这个数据类型的目的,这样做已经是我疲惫了.)这些额外的规则可以让编译器更高效的工作(原文此处有个词pedantic，我查了下竟然tmd是迂腐,我擦,但分析上下文此处作者并不是在表达反面的情感,偶然在一个角落里发现了这一段话,“如果使用-pedantic选项，GCC就可以基本上按照标准C/C++进行代码检测了，不要挑剔什么，迄今为止没有任何一款编译器完全支持标准C/C++的”,由此推断作者表达Swift额外的语法规则可以让Swift更接近C语言,编译器效率更高),但同样意味着这门语言将要让我们花更多的时间去学习.
ps:在此趁机百度了一下Optional的定义:
Optional是Objective-C没有的数据类型，是苹果引入到Swift语言中的全新类型，它的特点就和它的名字一样：可以有值，也可以没有值，当它没有值时，就是nil。此外，Swift的nil也和Objective-C有些不一样，在Objective-C中，只有对象才能为nil，而在Swift里，当基础类型（整形、浮点、布尔等）没有值时，也是nil，而不是一个初始值，没有初始值的值，是不能使用的，这就产生了Optional类型。定义一个Optional的值很容易，只需要在类型后面加上问号(?)就行了，如：
var str: String?
OC对程序猿更高.Swift这门语言把更多的工作交给了编译器而不是程序猿.这不正是程序猿想要的么?(这句我猜的~原文太屌),但是这样意味着当你在读一行代码的时候，如果你对这行代码的生命周期和所处的上下文没有很深刻的理解的话,它仅仅就是一行代码而已.
ps:对于这句话我又百度了下:
Objective-C语言的问题
当一个开发者申请一个关于Atomic Object的新职位时，我们会给他填写一个（GTKY） Getting To Know You的表。这个表要求填写一些常见的问题，包括技术和其他方面，比如你最喜欢的语言是什么，你会做些什么来改进它？很多开发者的回答不能令人满意，即使开发人员选择objective-C作为他们最喜爱的语言时，也想不出如何改进它！这个回答产生了大量的讨论，让我想起一个Objective-C的问题。仅举几例：
- 弱类型 - 通常处理id或class，并且需要可怕的C static casts 。
- 欠佳的枚举语法 - for in已经很好了，但我经常想到一个更好的索引。
- 缺少操作符重载的类，例如NSNumber的。
由此分析作者的意思是:OC的语法上能更好地帮助程序猿理解代码的含义,就算你第一次拿到别人写的代码,看到NSInteger a这种狗屎命名,就算你没学过OC,但根据你多年的编程经验你看到Integer起码能推断出a是个整数,但你要没学过Swift,看到一句Var a,你可能就要去下边找找了,看看这个a到底是个什么鬼.我还没有学过Swift,所以举得例子比较单薄,但我觉得意思和作者表达的差不多,帮助大家理解.
Swift有一堆OC没有的结构.例如,Swift的generics(传说中的泛型)能让编译器更好地进行类型检查,但却让这门语言变得更加复杂.
ps:又百度了下,在iOS9的OC中也引入了一种叫做Lightweight Generics(轻量级泛型)的技术,直接引用吧:阅读原文
带泛型的容器
这无疑是本次最重大的改进，有了泛型后终于可以指定容器类中对象的类型了：
NSArray *strings = @[@"sun", @"yuan"];
NSDictionary *mapping = @{@"a": @1, @"b": @2};
返回值的 id 被替换成具体的类型后，令人感动的代码提示也出来了：
假如向泛型容器中加入错误的对象，编译器会不开心的：
系统中常用的一系列容器类型都增加了泛型支持，甚至连 NSEnumerator 都支持了，这是非常 Nice 的改进。和 Nullability 一样，我认为最大的意义还是丰富了接口描述信息，对比下面两种写法：
@property (readonly) NSArray *imageURLs;
@property (readonly) NSArray *imageURLs;
不用多想就清楚下面的数组中存的是什么，避免了 NSString 和 NSURL 的混乱。
只要你了解OC,学习Swift是件很容易的事.
为了让Swift和OC能共用,苹果不得不让Swift和OC很相似.在Swift中链接OC类的对象是比较困难的，但是strong和weak，还有继承几乎和OC一样，只是用不同的语法表现出来而已.
说实话你先学哪一门语言并不重要；因为最终这两门语言你都会学会的.
综上所述,面对现实吧:你仍然需要学习OC.我建议先从 Objective-C Programming: The Big Nerd Ranch Guide或者我们的Beginning iOS bootcamp开始.
网友评论