面向介面程式設計詳解(三) 模式研究

2021-07-04 20:05:07 字數 3301 閱讀 5479

通過前面兩篇,我想各位朋友對「面向介面程式設計」的思想有了一定認識,並通過第二篇的例子,獲得了一定的直觀印象。但是,第二篇中的例子旨在展示面向介面程式設計的實現方法,比較簡單,不能體現出面向介面程式設計的優勢和這種思想的內涵。那麼,這一篇作為本系列的終結篇,將通過分析幾個比較有深度的模式或架構,解析隱藏其背後的面向介面思想。這篇我將要分析的分別是mvc模式和.net平台的分層架構。

這篇的內容可能會比較抽象,望諒解。

1.從mvc開始

mvc簡介:

本文不打算詳細解釋mvc架構,而是把重點放在其中的面向介面思想上。所以在這裡,只對mvc做乙個簡略的介紹。

mvc是一種用於表示層設計的復合設計模式。m、v、c分別表示模型(model)、view(檢視)、controller(控制器)。它們的職責如下:

模型:用於儲存應用中的資料及執行邏輯,是應用的實體。

檢視:負責可視部分,用於與使用者互動及呈現資料。檢視只負責顯示,不負責將使用者的操作行為解釋給模型。

控制器:負責將使用者的行為解釋給模型。根據指定的策略和使用者的操作,呼叫模型的邏輯。

圖3.1 mvc模式示意

它們之間的互動有以下幾種:

1.當使用者在檢視上做任何需要呼叫模型的操作時,它的請求將被控制器 截獲。

2.控制器按照自身指定的策略,將使用者行為翻譯成模型操作,呼叫模型相應邏輯實現。

3.控制器可能會在接到檢視操作時,指定檢視做某些改變。

4.當模型的狀態發生改變時,將通過某種方式通知檢視。

5.檢視可以從模型獲取狀態,從而改變自己的顯示。

mvc介紹完了,那麼可能會有人問,我們的主題呢?面向介面思想呢?其實,mvc中處處都存在面向介面的影子。下面,我對其中幾個側面進行解釋。

1.首先我們可以看到,檢視和模型是有直接互動的,也就是上面的4、5兩點。但是有一點可能會讓你吃驚:它們兩個誰也不「認識」誰,即它們相互並不知道對方是做什麼的、有什麼屬性、有什麼方法,但是它們能互動。這是怎麼做到的呢?因為它們個各知道對方實現了某乙個介面。

此乃面向介面思想一大作用:使相互不認識的類進行互動。這樣做是很有好處的,首先它們之間的耦合度大大降低,其次雙方都可以進行替換,只要實現了相同的介面,就沒有問題。

打個不太恰當的比喻。我們都知道120這個**號碼,是急救**。其實120就是個介面,因為當你撥打這個**時,你不知道那邊是哪所醫院,甚至不知道那邊是不是醫院,你只知道**那頭的地方可以救人,也可以說實現了ihelp介面。這樣,你通過乙個號碼可以說同全部的救人機構聯絡起來了,當有緊急事件,接線控制那邊會將你的請求接到最近可用的機構,你就可以最快的得到幫助。

現在我們假設沒有使用面向介面思想,來看看會發生什麼恐怖的事情:首先,我家的120號碼是繫結在本市第一人民醫院的,即當我撥打120時,只能撥通第一人民醫院。如果有一天我食物中毒了,急忙撥通了120,但是**那邊告訴我他們醫院的救護車都派出去了,我問那怎麼接通別家醫院的**,那邊的mm很溫柔的告訴我,讓我打**給網通公司,然後重新為我佈線。於是我**而亡……

言歸正傳。這裡,我要引入乙個設計模式,叫觀察著(observer)模式。這個模式大約是這樣的:整個模式中有兩種實體:觀察者和被觀察者,它們分別實現乙個介面,這裡我們姑且叫做iobserver與iobserversubject。iobserver只有乙個方法,例如叫update,當被觀察者狀態改變時,呼叫這個方法,用來通知觀察者。iobserversubject介面有兩個方法,都是供觀察者呼叫。乙個用來將觀察者註冊為此被觀察者的觀察物件,另乙個用於將觀察者移除。

一般情況下,乙個被觀察者對應多個觀察者。

在mvc中,檢視是觀察者,模型是被觀察者,當模型狀態改變時,呼叫所有觀察者的update方法,通知檢視模型有變,檢視在update方法裡寫下響應**,完成操作。通過這個方法,檢視和模型就可以在僅依賴介面的情形下進行互動,而不必強耦合,而且在模型不變的情況下,檢視可以隨意替換。(只要實現了iobserver)

2. 在mvc中另乙個使用介面的地方就是控制器,這裡我要首先引入乙個設計模式:策略模式(strategy)。在mvc中,控制器就使用了這個模式。

剛才我說過,檢視負責與使用者互動,但是,它只負責介面顯示部分,至於當使用者做了某個操作(如單擊某個按鈕)後系統應該怎麼反應,檢視並不負責,它只是將這個動作交給控制器,控制器根據內建的策略,將使用者操作翻譯成模型的邏輯。這就是說,同乙個檢視、同一種操作,模型可以做出不同的反應,這取決與控制器的內建策略。所以,我們的系統中可以有很多控制器,它們有不同的策略,當檢視希望改變策略時,它可以更換控制器。怎麼實現呢?這就需要檢視不能和具體控制器耦合,而是要僅依賴乙個控制器介面(如icontroller),並聚合乙個icontroller的例項。當希望更改策略時,可以在系統執行時動態更換controller,這就是策略模式的實現。

關於mvc的介面思想就先介紹到這裡。其實mvc中還有很多地方用到面向介面,由於本文不是專門介紹mvc或設計模式的,所以對用到的模式沒有做詳解,而是把重點放在其中的面向介面思想上。如果沒有設計模式的基礎,讀上文可能會有些困難,希望各位見諒!我打算在以後專門寫文章來解析mvc。

2..net平台下分層架構的面向介面思想

我們知道,在做大一點的系統應用時(特別是b/s架構),比較好的方法是分層架構。所謂分層架構,是指將系統從職責上分成若干層,每層各司其職,上層依賴下層完成操作。

在.net平台上,比較經典的分層架構是三層架構,從下到上依次是:資料訪問層、業務邏輯層、表示層。各層職責如下:

資料訪問層:負責與資料來源互動,完成資料訪問等一系列操作。

業務邏輯層:完成與系統業務有關的邏輯操作。

表示層:負責與使用者互動、呈現資料等一切與系統表示有關的操作。

剛才我們說過,分層架構下是向下依賴的(不考慮依賴倒置),也就是業務邏輯層要呼叫資料訪問層完成與資料來源有關的操作,而表示層呼叫業務邏輯層完成業務邏輯工作。但是,表示層對資料訪問層是沒有依賴的。

如果說,前面的例子都是從微觀視角討論介面,那麼,這個例子則從巨集觀視角展現了面向介面程式設計的內涵和優勢。很抱歉在這裡不能對這個架構深入講解,有興趣的朋友可以參考微軟的官方示例.net petshop4。(但是請注意,這個示例中業務邏輯層沒有定義介面族,而是強耦合於表示層中,這可能是因為考慮到在這個系統中業務邏輯沒有更改的可能。另外由於是個示例,不是真正的b2c系統,所以業務邏輯層很簡單。)

好了,本系列文章就到這裡。希望各位朋友通過這三篇文章,能對「面向介面程式設計」有一定的了解。當然,我只是起到乙個拋磚引玉的作用,其真正的內涵和精髓,還需要各位從實踐中慢慢認識。還有,就是面向介面思想不是孤立的,它和設計模式等內容都是物件導向大系中的精華,而且是相互滲透、相互聯絡的。其實,很多設計模式就是面向介面思想的體現。我們應該把這些放在一起學習,從而真正提供自己的物件導向思考能力和實戰能力。

面向介面程式設計詳解(三) 模式研究

通過前面兩篇,我想各位朋友對 面向介面程式設計 的思想有了一定認識,並通過第二篇的例子,獲得了一定的直觀印象。但是,第二篇中的例子旨在展示面向介面程式設計的實現方法,比較簡單,不能體現出面向介面程式設計的優勢和這種思想的內涵。那麼,這一篇作為本系列的終結篇,將通過分析幾個比較有深度的模式或架構,解析...

面向介面程式設計詳解(三) 模式研究

本系列 面向介面程式設計詳解 將分為三部分 面向介面程式設計詳解 一 思想基礎 已發布 在這一篇中,將對介面及面向介面程式設計有個大致的介紹,著重在於思想上的講解。面向介面程式設計詳解 二 程式設計例項 已發布 這一篇將結合乙個例項 移動儲存裝置模擬 來讓大家對面向介面程式設計有個直觀印象。面向介面...

面向介面程式設計詳解(三) 模式研究

通過前面兩篇,我想各位朋友對 面向介面程式設計 的思想有了一定認識,並通過第二篇的例子,獲得了一定的直觀印象。但是,第二篇中的例子旨在展示面向介面程式設計的實現方法,比較簡單,不能體現出面向介面程式設計的優勢和這種思想的內涵。那麼,這一篇作為本系列的終結篇,將通過分析幾個比較有深度的模式或架構,解析...