我正在构建一个我可能考虑开源的项目。我有一个UIView类别，它为我提供了设置x，y坐标或宽度的简单访问器，并直接留给了UIView，而不需要处理框架。 我的问题是，如果我计划开源，我应该在项目中使用这些类别吗？
许多项目都有类似的类别，包括UIView的方法，如
- (void)setLeft:(CGFloat)left;
或
- (void)setX:(CGFloat)x;
我的理解是，如果两个类别创建一个方法，你将无法保证将要调用哪个方法。
所以......我该怎么办？根本不使用类别并在我的开源项目中处理这个烦人的代码？使用类别并可能在方法名称前加上？
谢谢！
答案 0 :(得分：11)
不要费心添加这些方法。
他们保存很少的打字，你真正应该添加的前缀将是丑陋的，并且他们添加几乎没有真正的便利，同时使针对添加的API编写的代码不再可移植到缺少它的项目。
同样，拥有一堆便捷方法会使子类化变得更加困难。您必须覆盖哪种方法？ KVO的行为是什么？是否存在一种原始方法，即所有内容都是漏洞，或者您是否真的要覆盖所有内容？
框架通常不会添加这样的便利API，因为它会给API带来很多额外的“重量”，同时会引发上面提到的所有问题。所有这些额外的方法只是开发人员在向项目介绍新人时必须了解，记住并向他人解释的更多数据点。
一个例外是类集群类; NSString，NSArray等......他们有一组核心原始方法，提供实现其余API所需的所有功能。抽象类的其余方法完全根据这些原始方法实现。在子类化时，您只需要实现原语，所有其他行为将“正常工作”。但是，为了优化或定制目的，子类可以自由地覆盖任何非基元（但是，小心，你真的应该保留行为）。
一般的经验法则是，如果一个便利API不能定期保存多行代码，那就不值得了。
答案 1 :(得分：5)
由于Objective C不支持命名空间，因此如果您计划共享代码，则确保代码是唯一的常用方法是在方法前添加一些与您的项目特定相关的字母。
如果将setLeft和setX重命名为LMSetLeft和LMSetX，则应该大大减少发生碰撞的可能性。
只要您使用IDE的重构工具，这也应该是一个非常简单的更改。