简介
由于工作需要，项目有一次重写的机会。
有换Swift的想法，不过还是放弃了，熟悉了OC，有进度压力，还是选择了不变。
能抄的还是抄了，不过有些还是做了调整。
当然，如果没有进度压力，还是推荐使用Swift，OC真的到了该退出的时候了。
最外层结构
企业微信截图_8661ea7e-5649-4cb1-a773-1c7838dee03c.png
-
最顶层文件夹名称和工程名称一致
-
XCode默认生成的文件收集起来，放在一个文件夹中，比如SupportFiles之类的
这块内容尽量不改，但也不需要删，放着就好。 -
包管理工具还是选择CocoaPods，习惯了。虽然坑多，不过网上填坑的文章也多，还能折腾。（现在梯子是标配啊，没梯子的Pods还不如不用）
-
Pods文件夹也要上传代码库，第三方代码当做自己代码来管理，只是不能改而已。这样的话，只需要一个装梯子，一个人操作Pods命令就可以了。
-
PCH文件还是要一个的，名字跟工程名一样就可以了。与Swift，dart等语言相比，头文件真的太麻烦了。用上这个，稍微好一点点。
-
命名：一般是三个大写字母固定开头，这是OC特色。当然用两个字符也有，比如YY，但是三个字母还是主流，比如这里用了WGB；
主要模块
本着尽量精简，文件夹尽量少的原则，一个项目下来（这个可以说是最简单的项目了），以下几个文件夹还是有必要的。每个文件夹都配上一个同名的头文件，将对外接口统一结合起来，方便使用。
企业微信截图_6ec073a9-6124-407a-9957-253e0e767e1f.png
Page
页面的文件夹，一般是一个页面一个子文件夹。比如下面就是登录页面的内容。
企业微信截图_6df7f2a6-fec1-4f29-be54-4dc3136b8fda.png
- 接口文件一般和文件夹同名，并且做成类方法，是最方便使用的形式。比如显示登录页面，可以进行如下封装：
/// 显示登录对话框
+ (void)presentShow {
UIStoryboard *board = [UIStoryboard storyboardWithName:@"WGBLoginStoryboard" bundle:nil];
WGBLoginViewController *loginVC = (WGBLoginViewController *)[board instantiateViewControllerWithIdentifier:@"WGBLoginViewController"];
loginVC.modalPresentationStyle = UIModalPresentationFullScreen;
[[WGBControllerTool getRootViewController] presentViewController:loginVC animated:YES completion:nil];
}
使用的时候就非常方便，比如：
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
/// 检查登录，如果没有登录，显示登录对话框
if (![WGBLogin isLogin]) {
[WGBLogin presentShow];
}
}
- XXXManager一般是单例，直接对外使用，会有[XXXManager shareInstance]，还是有点麻烦，再包一层，变成静态方法，就更简洁了。比如：
/// 是否登录
+ (BOOL)isLogin {
return [WGBLoginManager shareInstance].isLogin;
}
Service
企业微信截图_39e7184d-6ed1-4697-ab1e-b5abc625aabc.png
-
服务，一般会做成单例，所以一般都有XXXManager
-
多一层封装，将单例的[XXXManager shareInstance]转化为静态方法，使用简单；
-
提供一个归总的WGBServiceHeader.h集中导出文件
#ifndef WGBServiceHeader_h
#define WGBServiceHeader_h
/// 个人信息
#import "WGBUserInfo.h"
/// 上传记录
#import "WGBUploadRecord.h"
#endif /* WGBServiceHeader_h */
Model
企业微信截图_f5092bdf-6caf-4798-9ae6-a8b963642533.png
-
以前，Model都放在各自的Page文件夹，不会单列出来。不过这次单列出来，感觉更合理。
-
胖Model还是瘦Model？果断瘦Model。从这个角度来说，Model是一种携带信息的数据结构，页面和网络接口的对接，就是靠Model来交换信息。
-
网络接口的响应还是需要Model的，直接使用Dictionary，字段是个麻烦事，不大好。
-
而给网络接口的参数，没有必要用Model，直接拼接Dictionary是最方便的。因为后台接口一般只认识Dictionary，不认识Model，直接给接口拼接字段反而是最方便的。
-
ViewModel应该跟具体的Page，跟View配对，不应该像Model一样独立文件夹。因为ViewModel是为了承接View的显示逻辑。Model是一种信息传递的数据结构，两者的作用有本质上的差异。
ToolKit
企业微信截图_e56a2bef-fc59-4e61-bf12-f2b61c6aa5b8.png
-
工具类，一般都是需要的。一个工程，分三层，感觉繁琐了；不分层，又太啰嗦了。分两层，抽象一些常用工具，都是需要的。
-
统一个对外导出头文件WGBToolKitHeader，使用起来还是很方便的。
-
包装成静态方法，使用起来还是最方便的。比如数组判空：
/// 是否为空
+ (BOOL)isEmpty:(nullable NSArray *)array {
if (array == nil) {
return YES;
}
if (array.count < 1) {
return YES;
}
return NO;
}
/// 是否不为空
+ (BOOL)isNotEmpty:(nullable NSArray *)array {
return ![self isEmpty:array];
}
BaseKit
企业微信截图_f9e5911d-4174-4b91-9066-0beb1863673a.png
- 基类封装：Model，ViewModel，view controller等等做个基类还是很方便的。比如，在基类控制器中打印一下页面退出log，对于排查内存泄露非常有帮助。
#pragma mark - life cycle
/// 打印页面退出信息
- (void)dealloc {
NSLog(@"页面：%@ 退出(dealloc)", NSStringFromClass([self class]));
}
-
多级继承是反对的，但是一级或者两级继承是推荐的。特别是这种基类继承是推荐的。
-
常数定义WGBConstant，宏定义WGBMacroHeader，配置信息WGBConfig等等集中在这里，最大程度公用。
网友评论