iOS软件开发框架理解

这个东西是硬伤,框架?自带的mvc? 自带的UIViewController UIView UINavigationController 这些算不算?当然算的,cocoa框架嘛,大家都知道。

其实,我想分享的是:整个软件设计的代码结构管理。在阅读了不少源码后,总结出来的好的设计代码结构分布逻辑。

一开始,我们学会了简单的使用UIButton,UIImage等这些常用的视图类的时候,我们其实已经能够写出来一般的软件了。常见的功能,这里添加一点,那里添加一点,这里一个网络请求,这里一个bool类型判断,例如常见的:isDownding? reLoading?

这些,我们经常在ViewController中就直接写了,于是,飞快的打出来:@property(nonatomic, assign)BOOL reLoading; 然后代码中,多处引用的地方进行处理。

而如果加上一个网络请求,数据柔和,加上几个成员变量,NSArray, NSDictionary, 什么的,再接着,多上几个又臭又长的正则匹配什么的。可以想象,这个ViewController已经非常长了。上图演示:

技术分享

好了,我们开始来改进代码了,第一步,把基本的view独立出来一个view文件的存放,分离出来。这样子至少省了3分之一的代码,再viewController中,而且极大的提高了代码阅读效率。直接看viewController就能看完整体逻辑。而可以先不管具体实现。

然后接着,我们又觉得还是不够,不够精简。对。于是,我们把数据独立出来。对抽象独立出来。建立专门的对象存储数据对象。可以发现,无一例外的,所有的大型软件都会这么做。也可以省了好多代码,提高阅读代码体验,极大的解耦了代码。这两种方法相当的基础,基本上做完了。至少代码可阅读了。入门了。现在的文件结构是这样的:

技术分享

好看了好多。

好了,我们已经基本排版好了文件结构以及基本的代码分布问题。但是,这只是入门了而已。

下面的就是基于软件的复杂度需求进行变更的:

1.抽离出来网络请求的部分:

  原因如下:a.网络请求,总会有错误返回码,能方便的增删查减,代码更容易找。

       b.网络请求,虽然自带的网络请求也是可以一句话,BLock返回处理结果,但是,要基于自己的业务逻辑进行封装,一定程度上减少藕合度,提高复用性。

       c.对于特俗的网络请求,例如http的post请求,就需要自己独立进行封装数据格式了。

 

2.基于数据的复杂度,进行相应处理,可以添加自己的业务逻辑的数据库处理操作。可以添加各种自定义类型的数据类。这样做的好处,也是抽离代码,减少耦合。

最后上传一张前人总结的,仅供参考的图片:

技术分享

这里的分类方式真的只能仅供参考,具体情况还要基于实际项目的分析,不能一概而论的。

That‘s all。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。