2017最新白帽子教程,持续更新中~~~

ButterFly iOS mass plan tech framework

Uncategorized toy 29℃ 0评论

ButterFly iOS mass plan tech framework
大家还记得小时候玩的乐高玩具,都是一个个小模块构成的,他们之间可以任意组合,正是这个idea,挽救了乐高。大学时候也看过谷歌推出的google phone,构想和乐高很像,将手机做成一个一个的模块,用户可以自定义自己的手机,按需购买模块。

butterfly的iOS群控项目,考虑到后续开发的高效敏捷性,也从项目成立初不久,着手做这个模块化方案。

首先将app进行划分,view模块,controll模块(常见展示布局),model模块(数据处理),常用功能模块(存储照片,定位分享,相机),每个模块也会有等级划分通用,主流,个性化

命名要求
个性化–不考虑在模块方案中,命名以项目前缀开始
主流–考虑在模块方案中,命名以Popular前缀开始
通用–考虑在模块方案中,命名以Normal前缀开始

项目初期每个独立都需要考虑这个等级划分,不断优化模块化方案

一点感悟
在软件设计中,经常说起“高内聚,低耦合”,高内聚就是要用模块的人,不去关心这个模块是用什么材质,用什么机器生产的,只是放心去用去拼接。低耦合就是让用的时候不要拼接的太麻烦,最好和乐高一样一插就好了,3岁小朋友都会。
但是低耦合,并不是说不要耦合,而是说要低,要操作方便。如果没有耦合,不能和其他模块拼接,那要这个模块还有什么用,这样就没法复用了啊。
对于view类型来说,其实就是2点,一个是给数据,一个是交互,交互还是数据变化的显示,所以view类型模块,暴露出来的,有2大类,一个是数据源代理(block,协议等等),一个是代理(其view本身可以感知交互,要将这个功能移交出去)。移交给controll模块,本身不做逻辑处理,只是拿数据,显示。其实,最经典的例子,不就是系统UITableView模块嘛,仔细想想,就是一个数据源协议,一个代理协议。我们封装的view模块,要像系统封装的学习。这个架构设计,其实软硬相通,万物相通,都是属于工程界问题,都是工程应用项目管理的必经路。长城不是一个人能修的,也不能全靠蛮力来修,合理分工,优化架构。

View模块类
导航类
导航–整屏幕均分[tag分类]

导航–UICollectionView超过一屏幕

转载请注明:链圈一盏灯 » ButterFly iOS mass plan tech framework

喜欢 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址