iOS 代码架构规范

iOS代码命名基础
iOS 命名方法

代码结构

• 可读性可维护性
• 一致性

代码布局应该风格统一

#import "TestViewController.h"

@interface TestViewController ()<UITableViewDelegate>

@property(nonatomic,strong)UIButton *configBtn;

@end

@implementation TestViewController

#pragma mark----------------------------------life cycle
- (void)viewDidLoad {
    [super viewDidLoad];
    
}
- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
}

#pragma mark----------------------------------UITableViewDelegate
- (NSInteger)tableView:(UITableView *)tableView indentationLevelForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 0;
}
-(UITableViewCell *)objectInConfigBtnAtIndex:(NSUInteger)index {
    return nil;
}

#pragma mark----------------------------------CustomDelegate
/*
 自己的代理
 */

#pragma mark----------------------------------event response
- (void)didTappedConfigBtn:(UIButton *)btn {
    
}

#pragma mark----------------------------------private method
/*
 私有方法
 */

#pragma mark----------------------------------getter and setter
- (UIButton *)configBtn {
    return nil;
}
- (UITableView *)tableView {
    return nil;
}

• 所有的属性都使用getter和setter

#pragma mark - life cycle
- (void)viewDidLoad
{
    [super viewDidLoad];

    self.view.backgroundColor = [UIColor whiteColor];
    [self.view addSubview:self.firstTableView];
    [self.view addSubview:self.secondTableView];
    [self.view addSubview:self.firstFilterLabel];
   
}

• 每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去
  比如UITableViewDelegate的方法集就写上#pragma mark - UITableViewDelegate,看的非常清晰。

• event response专门开一个代码区域
  把所有的UI 交互事件放到这里，看的非常清晰。

• 关于View的布局
  推荐Masonry，代码的可读性好。

• 关于继承
  建议能不用尽量不用，建议使用别的方案代替比如，组合。（这里有一篇说的很好）忘记继承

• 理解MVC的正确姿势
  M应该做的事：

  • 给ViewController提供数据
  • 给ViewController存储数据提供接口
  • 提供经过抽象的业务基本组件，供Controller调度

C应该做的事：

• 管理View Container的生命周期
• 负责生成所有的View实例，并放入View Container
• 监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。

V应该做的事：

• 响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。

• 界面元素表达

• 设计心法
  针对View层的架构不光是看重如何合理地拆分MVC来给UIViewController减负，另外一点也要照顾到业务方的使用成本。最好的情况是业务方什么都不知道，然后他把代码放进去就能跑，同时还能获得框架提供的种种功能。

  • 尽可能减少继承层级，涉及苹果原生对象的尽量不要继承
  • 做好代码规范，规定好代码在文件中的布局，尤其是ViewController
  • 能不放在Controller做的事情就尽量不要放在Controller里面去做
  • 构师是为业务工程师服务的，而不是去使唤业务工程师的