声明NSString属性的时候到底要不要采用copy限定词？

关于属性声明的限定词，我在下面这几篇文章中都有过介绍，这里不再赘述：

1，内存管理之MRC

2，Effective Objective-C 2.0——理解“属性”这一概念

3，Copy 和 Strong

通过这些文章，我们有了一个共识：在声明NSString类型的属性的时候需要采用copy内存管理策略。理由我在上面的文章中也做过详细介绍，这里不赘述。

但是也有人对上面👆的共识提出了自己的看法，理由主要有如下两点：

1，如果采用copy内存管理策略的话，就会在堆区另外开辟一块内存，这势必会增加内存的开销；

2，如果你这个字符串确定是可变的，那么就应该使用NSMutableString；如果我们声明一个NSString类型的字符串，那么这个字符串就势必不是可变的，此时如果你将该指针指向了可变字符串，那么就是你代码写得不够规范，就是你程序写得有问题。

需要注意的是，我上面说的是针对于在一般的业务场景开发过程中；在OC的语法层面，父类指针是可以指向子类对象的，如果现在是在开发一个工具，或者一个基准类，那么是不在本文的讨论范围之内的。

针对于上面第一种观点呢，我建议他们去读一读《Copy 和 Strong》，这篇文章中通过案例验证了这样一个观点：给NSString类型的变量进行copy，是浅拷贝，不会在堆区开辟内存。

接下来我们主要来聊一聊上面的第二个观点。

（1）OC是一门面向对象的语言，面向对象三大特性：继承、封装、多态，所以我们是可以通过声明一个父类指针，去指向不同的子类对象的。在封装的场景中，我们声明一个NSString类型的属性，它可能会指向NSString类型的变量，也可能会指向NSMutableString的对象，此时必须要使用copy，这一点问题没有。但是在日常的业务场景中，我们遇到的场景基本都是确定的，我们会明确地知道最终传递给NSString类型的指针的变量到底是NSString还是NSMutableString，这样的话，我们在最终赋值的时候就完全可以手动将变量转换一下（比如将mutableString给copy一下）再赋值给NSString。

一句话总结：封装基类不在本问题的讨论范围之内，我们讨论的是日常业务场景下的NSString的内存管理策略，日常的业务场景基本都是确定的场景，我们会明确知道最终传递给NSString指针的到底是NSString类型还是NSMutableString类型，如果是可变类型那么就给其copy一下再赋值给NSSTring类型的指针即可。（支持反方）

（2）根据第一条，我们要求声明String类型的属性的时候使用strong，但是要同时保证在业务场景下不能将NSMutableString类型的变量赋值给NSString类型的属性。这一点在理论上讲是没有毛病的，但是它更多的要求的是程序员在写代码过程中要有一个统一的自主意识，而这种统一的自主意识的养成是非常困难的，而且不稳固。比如，团队中新进来一个程序员，那么他这种意识的培养需要一定的时间；再比如，某一个程序员在写代码过程中一不注意忘记了这条意识，将mutableString赋值给了NSString，那么后期将很难查找到问题，因为它是符合OC语法的，只是不符合你们团队的规则而已。

如果上升到团队组织层面，也是一样的道理。一个团队如果想让它有序良好地发展，我们不能够只靠自主意识，我们靠的是规则。只有制定完善的规则，全员统一去遵守，才能够杜绝腐败、让国家让团队朝着健康有序的方向发展。如果完全靠自主意识，让团队成员自主而没有一个合理的规则去约束，那是不靠谱的；让一个团队领导者仅仅是靠自己的自制力，是很难保证岂不腐败的。

我们一个团队去制定代码规范，目的之一是统一代码风格以使代码更易懂，除此之外，还有一个很重要的原因是规避各种风险。上面第（1）条是说主要依靠程序员的自主意识和能力去规避风险，但是人非圣贤，任何人都有可能犯错，如果我们单纯的依靠程序员自身的意识和能力，那是不确定因素，与之相对的，通过代码规范、通过规则去约束，比通过程序员的自主意识和能力去约束要靠谱得多。上升到国家层面也是一样的道理，通过完善的法规去约束干部、抑制腐败比通过干部自身的自制力去进行自我约束要靠谱得多。

我在《Block以及Block的循环引用》中提到的解决循环引用的两个方案，其中打断一条腿靠的就是程序员自身对对象的生命周期有全面的认知，知道在哪会产生循环引用，知道在哪里打断这条腿，但是这强烈依赖程序员的个人能力，这是不确定的。而通过weak-strong dance这种规则来解决循环引用就确定、靠谱得多~

以上。