OC工程的文档组织 2023-04-26 周三

2023-04-25 本文已影响0人勇往直前888

简介

由于工作需要，项目有一次重写的机会。
有换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等等集中在这里，最大程度公用。