将选项卡式 UITableViewController 拆分为多个文件的好方法是什么？
我已经实现了一个选项卡式UITableViewController。顶部有一些选项卡可以重新加载表格的内容。根据所选选项卡，向用户显示不同的单元格。一切都很好，但我最终得到了一个包含 3 个不同实现的源文件，并且变得有点庞大和混乱，甚至使用编译指示来标记源代码的各个部分。
我考虑过在运行时根据所选选项卡从字符串创建选择器，然后将 .m 文件拆分为多个文件，将重命名的方法放在那里，但随后会出现强制的 @end 和文件末尾以及编译器告诉您缺少要实现的方法。
确实，看起来 Objective-C 并不是为了将源代码分割成多个文件而设计的。有没有可以用于此目的的设计模式？不知何故，我设法在主类的 @end 之前使用 #include 来模拟所有这些，但它看起来不太漂亮。另外，如果我尝试将该文件包含到项目中，Xcode 会感到非常困惑，因为它尝试单独编译它（至少我可以将文件包含在项目中并禁用它们包含在目标中）。
I've implemented a tabbed UITableViewController. There are some tabs on the top which reload the contents of the table. Based on the selected tab different cells are shown to the user. It all works nice, but I end up with a source file which contains 3 different implementations, and gets a little bit bulky and confusing, even using pragmas to mark sections of the source code.
I've thought of creating selectors at runtime from strings based on the selected tab, then splitting the .m file into several putting there the renamed methods, but then there's the forced @end and the end of a file and the compiler telling you that there are missing methods to be implemented.
Really, it looks like objective-c wasn't designed to split the source though several files. Is there any design pattern that can be used for this? Somehow I managed to emulate all this using #include <otherfile.m> before the @end of the main class, but it doesn't look pretty. Also, Xcode gets confused as hell if I try to include that file into the project, since it tries to compile it separately (at least I can include the files in the project and disable their inclusion in the target).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最后我求助于基本的预处理器，这意味着包括和一些技巧。这就是我所做的：
filename.m，为每个选项卡/相关功能组创建一个filename_functionality.m文件，并将方法放在那里。请注意，此文件中没有@implementation、@end、#include等，只有方法。filename.m的末尾和@end标记之前，添加必要的#include "filename_functionity.m"，其中有效地告诉预处理器将所有文件视为一个文件。此时，就可以了！然而，Xcode 仍然很烦人，尽管能够打开下级源代码文件，但它无法正确解析它们，因此您无法使用快速导航栏在方法之间跳转，例如例子。再次，为了解决这个更多的预处理器技巧：
在每个从属文件的开头，添加（糟糕，wiki 格式已损坏）：
#ifndef _INCLUDE_FILES@implementation BIEntity_view_controller#endif在从属文件末尾重复使用
ifndef括起来@end。_INCLUDE_FILES。它的作用是欺骗 XCode 认为这是一个正确的实现文件，因此语法突出显示、完成和导航栏按预期工作。
此设置的唯一小问题是 Xcode 无法正确报告从属文件中的行错误，它只是指向包含并保留在那里。现在，我必须右键单击行错误并选择在日志中显示，这会在正确的行号所在位置播撒完整的控制台消息。
如果您不编写糟糕的代码（呵呵）或使用外部文本编辑器，这并不是一个大问题，但如果您习惯使用快速修复键从一个错误中跳转，那么这会严重伤害您线到另一个。
通过这个技巧，我将一个 1151 行文件分成四个大小分别为 558、342、55 和 145 行的文件。现在，功能的相关性更好，并且代码仍然可以作为同一类的一部分工作，因此我不需要像使用类或接口等语言构造那样编写访问器。
In the end I have resorted to the basic preprocessor, meaning includes and some trickery. Here's what I've done:
filename.m, create onefilename_functionality.mfile for each tab/group of related functionality and put there the methods. Note that there is no@implementation,@end,#include, etc, in this file, just the methods.filename.mand just before your@endmarker, add the necessary#include "filename_functionality.m", which effectively tells the preprocessor to treat all the files as a single one.At this point, it works! However, Xcode is still really annoying, despite being able to open the subordinate source code files, it doesn't parse them properly, so you can't use the quick navigation bar to jump between methods, for example. Again, to solve this more preprocessor trickery:
At the beginning of each subordinate file, add (yuck, wiki formatting is broken):
#ifndef _INCLUDE_FILES@implementation BIEntity_view_controller#endifAt the end of your subordinate file repeat with
ifndefenclosing an@end._INCLUDE_FILES.What this does is trick XCode into thinking that this is a proper implementation file, so syntax highlighting, completion and navigation bars work as expected.
The only minor nit with this setup is that Xcode doesn't properly report errors for lines in your subordinate files, it just points to the include and stays there. Now I have to right click on the line error and select Reveal in Log which sows the full console message where the correct line numbers are.
This is not a big problem if you don't write bad code (hehe) or use an external text editor anyway, but will seriously hurt if you are used to the quick fix keys to jump from one error line to another.
With this trick I've split a 1151 line file into four of sizes 558, 342, 55 and 145 lines each. Now the functionality is better related and the code can still work as part of the same class, so I don't need to write accessors as would be the case if using a language construct like classes or interfaces.