《iOS应用架构谈 view层的组织和调用方案》笔记整理

结束前段时间的忙碌,近来工作没什么任务。就趁上班时间学习一点东西。

读完了Casa Taloyum的《iOS应用架构谈 view层的组织和调用方案》,写的很认真,很详尽,收获颇丰。着手整理下目前自己能领悟到的一些知识。

先分享下:http://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html

代码结构

  先声明一点,我们之所以注重代码结构和格式,是为了代码的可读性和后期的可维护性,当然仅仅凭此文中讲的,还不够。还应该再去了解下变量和方法的命名规则等,推荐一本书:effctive objective-c 2.0。另外对于一个码农来讲,每天面对“一坨”似的代码和结构清晰、格式整齐的代码,你想要哪个呢?好了,不啰嗦了。

直接上代码:

@interface ViewController ()

#pragma mark - propertys
@property (nonatomic, strong) UIButton *customBtn;

@end

@implementation ViewController

#pragma mark - life cycle
- (void)viewDidLoad;
- (void)viewDidAppear:(BOOL)animated;
- (void)viewWillAppear:(BOOL)animated;
.........

#pragma mark - UITableViewDelegate
.........

#pragma mark - CustomDelegate Or OtherDelegate
.........

#pragma mark - event response
.........

#pragma mark - private methods
.........

#pragma mark - getters and setters
.........

@end

详细说明下:

1.所有的属性都使用getter和setter

  不要在viewDidLoad里面初始化你的view然后再add,这样代码就很难看。在viewDidload里面只做addSubview的事情,然后在viewWillAppear里面做布局的事情,最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化,则交给getter去做。

比如这样:

#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];
    [self.view addSubview:self.secondFilterLabel];
    [self.view addSubview:self.cleanButton];
    [self.view addSubview:self.originImageView];
    [self.view addSubview:self.processedImageView];
    [self.view addSubview:self.activityIndicator];
    [self.view addSubview:self.takeImageButton];
}

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];

    CGFloat width = (self.view.width - 30) / 2.0f;

    self.originImageView.size = CGSizeMake(width, width);
    [self.originImageView topInContainer:70 shouldResize:NO];
    [self.originImageView leftInContainer:10 shouldResize:NO];

    self.processedImageView.size = CGSizeMake(width, width);
    [self.processedImageView right:10 FromView:self.originImageView];
    [self.processedImageView topEqualToView:self.originImageView];

    CGFloat labelWidth = self.view.width - 100;
    self.firstFilterLabel.size = CGSizeMake(labelWidth, 20);
    [self.firstFilterLabel leftInContainer:10 shouldResize:NO];
    [self.firstFilterLabel top:10 FromView:self.originImageView];

    ... ...
}

这样即便在属性非常多的情况下,还是能够保持代码整齐,view的初始化都交给getter去做了。总之就是尽量不要出现以下的情况:

- (void)viewDidLoad
{
    [super viewDidLoad];

    self.textLabel = [[UILabel alloc] init];
    self.textLabel.textColor = [UIColor blackColor];
    self.textLabel ... ...
    self.textLabel ... ...
    self.textLabel ... ...
    [self.view addSubview:self.textLabel];
}

这种做法就不够干净,都扔到getter里面去就好了。

2.getter和setter全部都放在最后

  因为一个ViewController很有可能会有非常多的view,就像上面给出的代码样例一样,如果getter和setter写在前面,就会把主要逻辑扯到后面去,其他人看的时候就要先划过一长串getter和setter,这样不太好。然后要求业务工程师写代码的时候按照顺序来分配代码块的位置,先是life cycle,然后是Delegate方法实现,然后是event response,然后才是getters and setters。这样后来者阅读代码时就能省力很多。

3.每一个delegate都把对应的protocol名字带上,delegate方法不要到处乱写,写到一块区域里面去

  比如UITableViewDelegate的方法集就老老实实写上#pragma mark - UITableViewDelegate。这样有个好处就是,当其他人阅读一个他并不熟悉的Delegate实现方法时,他只要按住command然后去点这个protocol名字,Xcode就能够立刻跳转到对应这个Delegate的protocol定义的那部分代码去,就省得他到处找了。

4.event response专门开一个代码区域

  所有button、gestureRecognizer的响应事件都放在这个区域里面,不要到处乱放。

5.关于private methods,正常情况下ViewController里面不应该写

  不是delegate方法的,不是event response方法的,不是life cycle方法的,就是private method了。对的,正常情况下ViewController里面一般是不会存在private methods的,这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category,要么把他做成一个模块,哪怕这个模块只有一个函数也行。ViewController基本上是大部分业务的载体,本身代码已经相当复杂,所以跟业务关联不大的东西能不放在ViewController里面就不要放。另外一点,这个private method的功能这时候只是你用得到,但是将来说不定别的地方也会用到,一开始就独立出来,有利于将来的代码复用

6.为什么要这样要求?

  ViewController,代码布局乱得一塌糊涂,这里一个delegate那里一个getter,然后ViewController的代码一般都死长死长的,看了就让人头疼。定义好这个规范,就能使得ViewController条理清晰,业务方程序员很能够区分哪些放在ViewController里面比较合适,哪些不合适。另外,也可以提高代码的可维护性和可读性。

  

时间: 2024-10-27 13:16:15

《iOS应用架构谈 view层的组织和调用方案》笔记整理的相关文章

iOS应用架构谈 view层的组织和调用方案(转~地址)

来自:iOS应用架构谈 view层的组织和调用方案 http://www.devzhou.com/2017/07/19/casa-ios-architecture-view/

iOS应用架构谈 view层的组织和调用方案

前言 <iOS应用架构谈 开篇>出来之后,很多人来催我赶紧出第二篇.这一篇文章出得相当艰难,因为公司里的破事儿特别多,我自己又有点私事儿,以至于能用来写博客的时间不够充分. 现在好啦,第二篇出来了. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了

iOS应用架构谈 view层的组织和调用方案(转)

前言 <iOS应用架构谈 开篇>出来之后,很多人来催我赶紧出第二篇.这一篇文章出得相当艰难,因为公司里的破事儿特别多,我自己又有点私事儿,以至于能用来写博客的时间不够充分. 现在好啦,第二篇出来了. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了

iOS应用架构谈(二):View层的组织和调用方案(上) 作者 田伟宇 发布于 2015年5月25日

iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.上篇主要讲View层的代码结构.布局,以及一些最佳实践的讨论. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在必须清楚认识到:View层的架构一旦实现或定型,在App发版后可

iOS应用架构谈(二):View层的组织和调用方案(中)

iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.中篇主要讨论MVC.MVCS.MVVM.VIPER等架构在iOS开发中的应用. 关于MVC.MVVM等一大堆思想 其实这些都是相对通用的思想,万变不离其宗的还是在开篇里面我提到的那三个角色:数据管理者,数据加工者,数据展示者.这些五花八门的思想,不外乎就是制订了一个规范,规定了这三个角色应当如何进行数据交换.但同时这些也是争议最

iOS应用架构谈(三):View层的组织和调用方案(下)

iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.下篇主要讨论做View层架构的设计的一些心法. 本门心法 重剑无锋,大巧不工. ---- <神雕侠侣> 这是杨过在挑剑时,玄铁重剑旁边写的一段话.对此我深表认同.提到这段话的目的是想告诉大家,在具体做View层架构的设计时,不需要拘泥于MVC.MVVM.VIPER等规矩.这些都是招式,告诉你你就知道了,然后怎么玩都可以.但是心

OS应用架构谈(二):View层的组织和调用方案(中)

OS应用架构谈(二):View层的组织和调用方案(中) 作者 田伟宇 发布于 2015年5月28日 | 注意: ArchSummit全球架构师峰会(北京)2015年12月18-19日,了解更多详情!讨论 分享到:微博微信FacebookTwitter有道云笔记邮件分享 稍后阅读 我的阅读清单 iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.中篇主要讨论MVC.MVCS.MVV

iOS应用架构谈-part2 view层的组织和调用方案

前言 <iOS应用架构谈 开篇>出来之后,很多人来催我赶紧出第二篇.这一篇文章出得相当艰难,因为公司里的破事儿特别多,我自己又有点私事儿,以至于能用来写博客的时间不够充分. 现在好啦,第二篇出来了. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了

[转] iOS应用架构谈 网络层设计方案

原文地址:http://casatwy.com/iosying-yong-jia-gou-tan-wang-luo-ceng-she-ji-fang-an.html iOS应用架构谈 开篇 iOS应用架构谈 view层的组织和调用方案 iOS应用架构谈 网络层设计方案 iOS应用架构谈 动态部署方案 iOS应用架构谈 本地持久化方案 前言 网络层在一个App中也是一个不可缺少的部分,工程师们在网络层能够发挥的空间也比较大.另外,苹果对网络请求部分已经做了很好的封装,业界的AFNetworking