原 封装（二）
发表于2年前(2013-12-08 18:09) 阅读（
312） | 评论（
1）
3人收藏此文章, 取消收藏
赞
0
摘要
这回我们来拿整个界面的封装说事
整个界面从封装的角度上来看，其实与某个控件是一样的。
为什么整个界面都要封装呢？
在项目开发过程中，我们往往会碰到一系列相似度比较高的界面，只是内容不同或少部分界面UI不同。这时，我们可以将共性的东西抽出来，封装成界面类。这样的界面类可以在整个项目中被各界面方便的重用，也可以跨项目的重用。最经典的例子就是“设置界面”。
一个界面同样也有输入、输出及特定的完成功能。我们来看看比较常见的列表选择跳转下一个详情界面的例子。
代码较多，这里就不写了。用伪代码来演示
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
／／列表界面 展示一个列表 从服务器获取数据，更新数据源 刷新列表显示最新数据 当点击某个列表行的时候，根据列表行的索引值，从数据源里获取对应的数据 创建详情界面 将数据作为参数传递给详情界面 在屏幕上显示详情界面 ／／详情界面 展示一个详情页面 对外部传递进来的参数进行处理，形成本界面独特的数据源 根据数据源刷新整个界面 |
上面的伪代码演示了从列表界面切换详情界面的一般过程。
请注意 “将数据作为参数传递给详情界面”这个地方。
同样有两种做法：
1、在列表界面准备好所有数据，传递给详情界面。详情界面用外部传递进来的数据更新界面元素。
2、在列表界面仅下载自身需要的数据，只传递给详情界面一个ID号或一个名字之类的索引值。详情界面根据外部传递进来的索引，自己到服务器去获取需要的数据。
我们来分析一下优缺点：
采用第一种方法，多个界面重用详情界面类。因为上一界面是不同的列表界面，有时甚至不是列表界面，无法获取相应的数据，需要在其他界面代码里访问服务器，下载数据，然后传递给详情界面。增加了其他界面的复杂度。
当详情界面版本升级，所需要的数据发生变化，必须修改所有涉及到的上层界面代码。
这种不方便，在一种情况下达到了极致。这种情况就是“处理推送消息”。
当我们接收到一条推送消息时，需要解析推送过来的消息内容，根据内容跳转到指定的界面。比如收到一条“某某评论了你的某篇文章”。
第一种方法需要在appDelegate里下载那篇文章的详情，然后创建详情界面、传入数据、在界面上显示。当接收的推送种类比较多，不是一种，而是10种，则必须在appDelegate里准备10种不同服务器接口的代码。
第二种方法，仅需要将某个特定ID传递给对应的界面，就不用管了。
由此，我们可以体会到封装的第二条原则：
谁的事情就让它自己来做，不要去做不是自己范围的事情。
封装类提供的对外接口越简单，越少，则通用性和安全性越高。