设计思路的一些总结

本文用于记录一些零碎的设计思路。不定时更新中......

1.库的传参

封装库即封装第三方,当需要让外界定制时(类似页面的跳转传参,只是项目中页面的跳转一般参数不多),主要有以下几种方式:

① 参数直接传入

参数直接传入适用于大部分场景,不过参数多了也显得繁琐,所以可能会通过分成多个Config模型类传入。参数传参的时机也是即时的。
参数可能通过属性,也可能通过函数参数,在Swift中,函数参数提供的扩展性很强,你可以通过枚举数组[options]达到自定义的效果。

② 通过协议数据源传入

参数传入是即时的,通过数据源是在必要的时候从外界获取。这个的好处是可以再适当的时机去处理需要的数据传入。同时作为一个封装库,也是需要通过代理回调给外界,这边不赞同使用闭包(代码块)。
协议可以作为数据源和代理的桥梁,在适当时机获取需要的参数,在多个时机获取对应回调。

③ 通过模型类传入

模型类传入,有点参数传入的意思,这边的模型类不仅仅是我们常见的Model,也比如Moya中的Target、CTNetworking中的BaseManager,将特异性的参数封在内部。

2.协议的使用

在OC中,协议似乎和代理绑在一起,其实不然。无论在OC还是Swift中,协议的用处都是很大的:

① 代理回调和数据源

UITableView是最典型的例子,TableView在适当时机从ViewController获取需要的参数,在多个时机回调给ViewController,让它去做事情。
(比如在我们不想把数据带过去处理或者数据带来带去,就可以在原本界面处理给下一个界面。)

② 约束类

这边有两种场景:

  • 一个是约束函数的参数,只能传入符合该协议的对象,比如在设置代理的时候。
  • 一个是约束类的方法,在AFNetWorking中,AFURLRequestSerialization是一个协议,规范类的主要功能。无论是AFHTTPRequestSerializer还是它的子类AFJSONRequestSerializer,都会去实现这个功能。
@interface AFHTTPRequestSerializer : NSObject <AFURLRequestSerialization>

@interface AFJSONRequestSerializer : AFHTTPRequestSerializer

在Swift中,这种规范就更加常见了,比如Moya的Target协议规范了作为一个Request模型类该实现的功能。

另外,多层回调传递(比如cell中的view代理要传递方法至cell所在的vc)可以通过两层Delegate(ViewDelegate,CellDelegate(继承于ViewDelegate))。

3.区分类的职责

封装一个库,除了考虑怎么传参和回调,更重要的是库的设计。库的设计简单说就是分成几个类?每个类担任什么职责?每个类的关系是怎么样?
在CTNetworking的设计中,简单的请求集合着不同的扮演者,有的负责提供数据(数据源),有的负责校验(检验者),有的负责回调(回调者),有的负责处理数据(适配器)。

4.ViewController继承的使用

ViewController的继承要分离好子类和父类各自的职责。
比如ImagePickerPreviewViewController(大图浏览界面)的父类用于封装ImagePreviewView的手势操作和动画。ImagePickerPreviewViewController自身用于添加外表的ToolBar,处理数据,处理代理方法。

当然使用继承有3大要点:
1.父类只是给子类提供服务,并不涉及子类的业务逻辑。
2.层级关系明显,功能划分清晰,父类和子类各做各的。
3.父类的所有变化,都需要在子类中体现,也就是说此时耦合已经成为需求。
其他情况下优先考虑组合。

5.配置类的设计

配置类(比如Config)大多数也是当作参数注入我们的项目模块,实现自定义设置的。
在UICollectionView中,Layout类本身也是类似配置类(通过协议限定我们实现的方法),负责提供布局所需要的信息。简单理解就是,我需要这些配置信息,你实现给我。
一个好的庞大的配置类,需要将配置做分割,将对应小模块的配置分配到各自的小配置中。比如网易云信的NIMKitConfig这个类就设计得不错,多而不杂。

6.相似界面的设计

相似界面的设计主要有两种思路,一种是继承,一种是配置。当然混合起来也是可以的。
继承主要应用于两个界面的控件有递进的关系。基类搭建基础控件,子类添加个性化的控件。
配置主要用于两个界面比较相似,界面控件、控件布局或界面参数通过配置类的方法来决定。

7.聊天界面的设计

聊天界面要想实现自定义,解耦,首先有UI层面和数据层面的区分。UI层面当然在ViewController去实现,自定义的内容可以通过配置类来提供,不同的配置类决定这个界面的一些不同之处。比如聊天界面的背景图,icon,或者聊天菜单选项,转发菜单选项,当然还有最重要的数据提供者(主要负责提供下拉请求聊天数据)。不同的数据提供者提供的数据也是不一样的,很明显的数据和UI做了解耦。

8.聊天Cell的设计(相似Cell的设计)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342