封裝（二）

   整個界面從封裝的角度上來看，其實與某個控件是同樣的。

   爲何整個界面都要封裝呢？

   在項目開發過程當中，咱們每每會碰到一系列類似度比較高的界面，只是內容不一樣或少部分界面UI不一樣。這時，咱們能夠將共性的東西抽出來，封裝成界面類。這樣的界面類能夠在整個項目中被各界面方便的重用，也能夠跨項目的重用。最經典的例子就是「設置界面」。

    一個界面一樣也有輸入、輸出及特定的完成功能。咱們來看看比較常見的列表選擇跳轉下一個詳情界面的例子。

   代碼較多，這裏就不寫了。用僞代碼來演示

／／列表界面

展現一個列表
從服務器獲取數據，更新數據源
刷新列表顯示最新數據

當點擊某個列表行的時候，根據列表行的索引值，從數據源裏獲取對應的數據
建立詳情界面
將數據做爲參數傳遞給詳情界面
在屏幕上顯示詳情界面

／／詳情界面

展現一個詳情頁面
對外部傳遞進來的參數進行處理，造成本界面獨特的數據源
根據數據源刷新整個界面

    上面的僞代碼演示了從列表界面切換詳情界面的通常過程。

    請注意 「將數據做爲參數傳遞給詳情界面」這個地方。

一樣有兩種作法：

一、在列表界面準備好全部數據，傳遞給詳情界面。詳情界面用外部傳遞進來的數據更新界面元素。

二、在列表界面僅下載自身須要的數據，只傳遞給詳情界面一個ID號或一個名字之類的索引值。詳情界面根據外部傳遞進來的索引，本身到服務器去獲取須要的數據。

咱們來分析一下優缺點：

    採用第一種方法，多個界面重用詳情界面類。由於上一界面是不一樣的列表界面，有時甚至不是列表界面，沒法獲取相應的數據，須要在其餘界面代碼裏訪問服務器，下載數據，而後傳遞給詳情界面。增長了其餘界面的複雜度。

    當詳情界面版本升級，所須要的數據發生變化，必須修改全部涉及到的上層界面代碼。

這種不方便，在一種狀況下達到了極致。這種狀況就是「處理推送消息」。

    當咱們接收到一條推送消息時，須要解析推送過來的消息內容，根據內容跳轉到指定的界面。好比收到一條「某某評論了你的某篇文章」。

    第一種方法須要在appDelegate裏下載那篇文章的詳情，而後建立詳情界面、傳入數據、在界面上顯示。當接收的推送種類比較多，不是一種，而是10種，則必須在appDelegate裏準備10種不一樣服務器接口的代碼。

   第二種方法，僅須要將某個特定ID傳遞給對應的界面，就不用管了。

由此，咱們能夠體會到封裝的第二條原則：

誰的事情就讓它本身來作，不要去作不是本身範圍的事情。

封裝類提供的對外接口越簡單，越少，則通用性和安全性越高。