所以我一直在构建应用程序一段时间，随着时间的推移，我的一个类（一个UIViewController）变得非常大，用一个视图做了很多东西。因此，我必须使其符合许多协议（现在12个）。我现在开始担心我会遵守一些太多的东西。
在一个类中是否符合许多协议？是否有性能损失或类似的东西？我不是在寻找个人意见，而是寻找可能的性能问题，或者是针对最佳实践/风格指南文档（例如Apple发布的文档）。
我的类符合的一些协议（不包括一些自定义协议）：
UIAlertViewDelegate, UIActionSheetDelegate, MFMailComposeViewControllerDelegate,
UITableViewDataSource, UITableViewDelegate, UITextFieldDelegate,
UIPopoverControllerDelegate, UIBarPositioningDelegate,
ABPeoplePickerNavigationControllerDelegate
修改 的
正如一些答案所指出的那样，大多数协议都与UI相关 - 并且视图本身并不杂乱。 UIAlertViewDelegate，UIActionSheetDelegate，MFMailComposeViewControllerDelegate和ABPeoplePickerNavigationControllerDelegate都会单独显示（在最后两种情况下以模态方式显示）。 UITableViewDataSource和UITableViewDelegate只是处理表格。 UITextFieldDelegate用于管理对字段的搜索（以便允许我检查输入的文本是否“有效”）。 iOS7需要UIBarPositioningDelegate才能显示。
这个类不是太大而且只处理自己，没有太多耦合（至少在我看来）。
答案 0 :(得分：1)
来自官方苹果文档：
提示：如果您发现自己采用了大量协议 类，这可能表明你需要重构一个过于复杂的东西 通过将必要的行为分成多个较小的类来分类 课程，每个课程都有明确的职责。一个相对 新OS X和iOS开发人员的常见缺陷是使用单一的 应用程序委托类包含应用程序的大部分 功能（管理底层数据结构，提供数据） 多个用户界面元素，以及响应手势 和其他用户交互）。随着复杂性的增加，班级 变得更难维持。
所以答案是在性能方面这样做并不坏，但这不是一个好习惯。
答案 1 :(得分：1)
让一个符合变化许多协议的类没有惩罚 - 除了可忽略的更高编译时间/空间（由于该类具有更大的编译表，但这实际上没有意义，IMO）并且可能是一个类可读性问题。
实际上，当您指定一个类符合协议时，您只是告诉编译器将该协议内部声明的所有方法添加到类接口。这对性能或内存占用几乎没有影响。
您遇到的主要问题是IMO关于类可读性的问题。一般情况下，当您的课程提供太多公共方法时，您会遇到问题。这使得难以理解该课程的用途。强烈建议重构，但同样，这与性能无关。
根据您粘贴的内容，您添加到类中的协议似乎与您在该类中管理的UI元素相关。然后，您所管理的视图过于复杂，或者您需要这些代理。
答案 2 :(得分：1)
一般来说，编程的最佳实践是尽可能地分离关注点和功能。对我来说，看起来你的应用程序包含一个拥挤的控制器。这是为什么？一个类或文件中的代码太多会使调试和维护变得更加困难，如果你的接口中包含所有这些元素，那么你的界面必须非常混乱。如果没有看到更多的代码，我就无法给出具体的建议，但总的来说，你在一个控制器中有太多东西。
答案 3 :(得分：0)
我认为这不会导致任何性能问题或错误。
但似乎你的课程非常耦合，这是一个糟糕的设计实践，但这不是必须的，你上课的代码行数是多少？
如果那很多而且你堕落了，那么你上课就做了一些不应该做的工作，你就不能折射你的代码了。
答案 4 :(得分：-1)
如果没有实际看到代码，我无法告诉你有关性能的信息，但是如果两个或更多协议以某种方式声明 同名的 方法（它发生在我身上）可能然后你会得到意想不到的行为，其中可能包括性能下降。假设两个协议定义了一个基本方法，例如- (void)update，现在您只实现了一种更新方法，但是两种协议都希望使用它，因此最多会有太多的更新调用（性能下降）。如果其中一个协议将方法定义为@optional，那么它并不总是立即显而易见发生了坏事。
我可以告诉你的是，这种单片设计普遍被认为很差。听起来你有一个很大的ball of mud。