面向介面程式設計

2022-03-14 07:22:26 字數 1647 閱讀 8004

面向介面程式設計

一般在實現乙個系統的時候,通常是將定義與實現合為一體,不加分離的,我認為最為理解的系統設計規範應該是所有的定義與實現分離,儘管這對於系統中某些複雜的情況有些繁煩。

面向介面程式設計設計

使用面向介面程式設計思想將層與層之間通過介面依賴,下層不是直接給上層提供服務,而是定義一組介面供上層呼叫。至於具體的業務實現,是開發中需要做的事情,在專案架構階段,只需要定義好層與層之間的介面依賴,將框架搭建起來,編譯可以直接通過。

為什麼要有面向介面程式設計設計?

為了提高架構的靈活性,降低層和層之間的依賴(耦合)

在乙個系統框架中乙個介面層可以根據不同的業務對應的有不同的實現層提供服務。

舉個例子 多層架構中,前後端分離的情況下前端只做一些弱邏輯處理,表現層只控制網路請求的輸入輸出(通過ibll介面和業務邏輯層依賴),業務邏輯層執行和處理強邏輯,對應不同的業務可以編寫不同的服務(ibll介面 提供bll.pc或者bll.mobile多套服務)供表現層呼叫,

資料持久化層一般只做一些原子性的操作

資料持久化層大部分使用關係型資料庫,也有使用搜尋引擎的還有檔案系統,非關係型資料庫的

依賴倒置

在軟體設計原則中,有一種重要的思想叫做依賴倒置。它的核心思想是:不能讓高層元件依賴底層元件,而且,不管高層元件和底層元件,兩者都應依賴於抽象。

那麼,這個原則和我們上面的原則是否矛盾呢?其實並不矛盾。

因為這個原則定義中的「依賴」是指「具體依賴」,而上面定義中的依賴全部指「抽象依賴」。我對這兩種依賴的定義如下:

具體依賴——如果p層中有乙個或乙個以上的地方例項化了q層中某個具體類,則說p層具體依賴於q層。

抽象依賴——如果p層沒有例項化q層中的具體類,而是在乙個或乙個以上的地方例項化了q層中某個介面,則說p層抽象依賴於q層,也叫介面依賴於q層。

依賴注入:

我們設計的分層架構,層與層之間應該是鬆散耦合的。因為是單向單一呼叫,所以,這裡的「鬆散耦合」實際是指上層類不能具體依賴於下層類,而應該依賴於下層提供的乙個介面。這樣,上層類不能直接例項化下層中的類,而只持有介面,至於介面所指變數最終究竟是哪乙個類,則由依賴注入機制決定。

層次劃分:

目前,典型的分層架構是三層架構,即自底向上依次是資料訪問層、業務邏輯層和表示層。

資料訪問層——負責與資料來源的互動,即資料的插入、刪除、修改以及從資料庫中讀出資料等操作。對資料的正確性和有效性不負責,對資料的用途不了解,不負擔任何業務邏輯。

業務邏輯層——負責系統領域業務的處理,負責邏輯性資料的生成、處理及轉換。對流入的邏輯性資料的正確性及有效性負責,對流出的邏輯性資料及使用者性資料不負責,對資料的呈現樣式不負責。

表示層——負責接收使用者的輸入、將輸出呈現給使用者以及訪問安全性驗證。對流入的資料的正確性和有效性負責,對呈現樣式負責,對流出的資料正確性不負責,但負責在資料不正確時給出相應的異常資訊。

在乙個系統框架中乙個介面層可以根據不同的業務對應的有不同的實現層提供服務。

舉個例子 多層架構中,前後端分離的情況下前端只做一些弱邏輯處理,表現層只控制網路請求的輸入輸出(通過ibll介面和業務邏輯層依賴),業務邏輯層執行和處理強邏輯,對應不同的業務可以編寫不同的服務(ibll介面 提供bll.pc或者bll.mobile多套服務)供表現層呼叫,

資料持久化層一般只做一些原子性的操作

資料持久化層大部分使用關係型資料庫,也有使用搜尋引擎的還有檔案系統,非關係型資料庫的

面向介面程式設計

面向介面程式設計 英文的定義是 program to an inte ce,not an implementation 它是物件導向程式設計裡面的乙個設計原則。所謂原則,就是 你最好按我的樣子來做,實在不行也可以違反 物件導向程式設計有三個主要的特性,即是封裝,多型,繼承。面向介面程式設計是多型特性...

面向介面程式設計

物件導向設計裡有一點大家已基本形成共識,就是面向介面程式設計,我想大多數人對這個是沒有什麼覺得需要懷疑的。問題是在實際的專案開發中我們是怎麼體現的呢?難道就是每乙個實現都提供乙個介面就了事了?反過來說,你有時候有沒有覺得介面是多餘的事?又或者,你僅僅是覺得現在類似spring這樣的框架已習慣用介面這...

面向介面程式設計

上篇我們了解了當依賴注入與面向介面程式設計結合起來,才能真正發揮依賴注入的優勢。這篇我們開始簡單了解一下面向介面程式設計。什麼是面向介面程式設計?乙個類依賴其他類的目的是為了獲取其他類所提供的服務,可能這種服務有多種實現,我們可能需要根據不同的場景使用不同的實現。此時,我們可以使用多型,將同一功能的...