封装（二）

原 封装（二）

发表于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传递给对应的界面，就不用管了。

由此，我们可以体会到封装的第二条原则：

谁的事情就让它自己来做，不要去做不是自己范围的事情。

封装类提供的对外接口越简单，越少，则通用性和安全性越高。