1. 程式人生 > >機房重構再看外觀模式

機房重構再看外觀模式

在機房重構的剛開始過程中,我對於每一個功能都建立了一個外觀層,所以剛開始我感覺外觀怎麼沒有起到應起的作用呢,只是簡單地降低了U層和B層之間的耦合,用於傳遞引數,把UI層的引數傳遞給外觀,然後再有外觀層把引數傳遞給B層,後來跟小胖交流,才發現還是沒有理解外觀模式的用處,所以才導致了下面的問題,於是重新開始翻開書重新理解外觀到底是幹什麼用的。

這裡寫圖片描述
這是剛開始學習設計模式時總結的一篇部落格:外觀模式。當初只是知道外觀層減少了客戶端和系統的互動過多的問題,然後讓一個外觀作為一個統一的介面。
但是這個介面是幹嘛用的?這個接口裡有什麼內容呢?現在才明白,在一個外觀類裡,可以去組合多個子系統類,決定了由哪幾個子系統類來執行。通過一個外觀類,就可以實現客戶端對多個子系統的訪問。
這裡寫圖片描述

機房外觀:
‘學生上機
Public Function CheckInquireOnline(ByVal cardInfo As JFEntity.CardInfo) As Boolean
Dim checkExitCard As New JFBLL.checkExitCardBLL ‘判斷卡號是否存在
Dim checkOnMoney As New JFBLL.checkOnMoneyBLL ‘判斷餘額
Dim checkOn As New JFBLL.checkOn ‘判斷是否在上機

    '定義繼任者
    checkExitCard.setsuccessor(checkOnMoney)
    checkOnMoney.setsuccessor(checkOn)

    Return checkExitCard.handlecheck(request)

End Function

End Class

在學生上機的外觀裡,定義了三個B層的類,這樣就減少了UI層和B層之間互動過多的問題。

學習就是一個循序漸近,盲人摸象的過程,剛開始理解的不是很深刻,但是在後面的學習過程中又會有自己不一樣的認識和理解。

相關推薦

機房重構外觀模式

在機房重構的剛開始過程中,我對於每一個功能都建立了一個外觀層,所以剛開始我感覺外觀怎麼沒有起到應起的作用呢,只是簡單地降低了U層和B層之間的耦合,用於傳遞引數,把UI層的引數傳遞給外觀,然後再有外觀層把引數傳遞給B層,後來跟小胖交流,才發現還是沒有理解外觀模式的

機房收費系統合作版】——外觀模式

前言:這次合作版機房,在小夥伴們的商量下,決定使用外觀模式。由於個人版的時候,因為各種原因,未能使用這一模式。現在,藉著這次機會,重新認識一下這位故友。 我們先看下邊的一張圖:     這張圖

C#機房重構之單例模式應用

前言 好久沒好好寫部落格了,掐指一算,2個多月了。今天給大家帶來一篇實用的單例模式實現攻略。   正文 單例模式的目的 我們的機房重構總是有一個主窗體,在主窗體中開啟其他窗體時,其實只要你願意是可以不斷開啟100個的。但如果這樣,既影響使用者體驗,又無實際意義。這時

C#機房重構之職責鏈模式

B層 public class ChainBLL { public void inquiryBasicInfo() { //呼叫工廠方法建立介面 Factory.BasicDataFactor

C#機房重構-下機(策略模式

策略模式 策略模式:定義演算法家族,分別封裝,讓它們之間可以相互替換,此模式計演算法的變化,不會影響到使用演算法的客戶。策略模式封裝了變化,只要在分析過程中聽到需要在不同時間應用不同的業務規則,就

外觀和B層

機房重構時候,用到了外觀,但是在用外觀的時候基本上業務邏輯層沒有在體現出它本身的功能,而是將 業務邏輯基本轉移到了外觀層中,也沒想太多直接就那麼敲完了重構;不過在合作的時候我們達成了一致,

結合laravel Facade外觀模式怎麼用?

  當獨立子系統的開發完成後,如果兩個系統是客戶-供應商關係,也就是說其中一個子系統(客戶)需要使用另一個子系統(供應商)提供的服務時,我們可以通過外觀模式來對客戶子系統隱藏呼叫供應商系統的複雜性,客戶端只需通過facade呼叫相應的服務而無需涉及供應商具體的服

【C#】單例模式<機房重構>

機房 .sh 不能 是否 gist 應用 調用方法 單例模式 sender 前言 在機房重構之前。我們學習了設計模式。在這次重構中,我們的任務就是將這些模式,加入到機房的重構中去。如今先來解決一個最簡單的問題——窗口的超生。 假設不加以限

以jq為案例套餐服務---外觀模式

前言 套餐服務--外觀模式,屬於大類結構型設計模式的一種,通常是為一組複雜的子系統介面提供一個更高階的統一介面,通過這個介面讓使用者對子系統的介面更加容易訪問。 在js中有時也會對底層結構相容性做統一的封裝來簡化使用者的使用。 備註:本文的案例以es5為主,部分會涉及jq的程式碼,大家理解思想

機房重構】——下機(策略模式+職責鏈模式

【前言】 下機功能在整個機房收費系統中也算是一個難點吧,因為下機的過程中涉及到的表比較多,有不同的收費標誌。針對這些要點,我分別採用了職責鏈模式來實現分段計費,策略模式來實現不同使用者的收費標準。下面請看我一一道來。   【內容】 一、什麼是策略模式  

C#機房重構-實時檢視上機餘額(狀態模式

狀態模式 狀態模式:當一個物件的狀態發生改變時,允許改變其行為。當控制一個物件狀態轉換的條件表示式過於複雜時,把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中,可以把複雜的判斷邏輯簡化。 具體實現 UI層 Entity.Gloable.Time =

機房收費系統(三)—組合查詢

寫在前面: 組合查詢顧名思義是多條件查詢,關鍵就是確定在一定的條件下需要查詢與這個條件想對應的內容,確定好查詢內容之後,每一次查詢都是在上一個條件基礎上加一個條件的查詢。 下面就看一下機房中複合查詢

外觀模式——透過現象本質

外觀模式用於為複雜系統建立一個簡單清晰的介面。 當我們需要使用到子系統的程式碼時,為了避免過去深入地呼叫子系統程式碼而導致後期程式碼難以維護,減低程式碼和子系統的耦合性,我們需要在程式碼和子系統中引入一個入口。實際上就是在子系統程式碼進行一次封裝,那麼我們在呼

結合Mybatis源碼設計模式——外觀模式

外觀 color spa 參數 完全 是你 ins clas inf 定義   提供了一個統一的接口,用來訪問子系統中一群接口 適用場景 子系統復雜,增加外觀模式提供簡單調用接口 構建多層系統結構,用外觀對象作為每層入口 詳解   外觀模式,主要理解外觀。

java設計模式外觀模式

數據 開發 移位運算 傳遞 保存 load space 法則 rep 【學習難度:★☆☆☆☆,使用頻率:★★★★★】 外觀模式是一種使用頻率非常高的結構型設計模式,它通過引入一個外觀角色來簡化客戶端與子系統之間的交互,為復雜的子系統調用提供一個統一的入口,降低子系統與

2015-03-12---外觀模式,建造者模式(附代碼),觀察者模式(附代碼),boost庫應用

思想 err map 函數 成功 each clu all 說我 今天白天主要看了boost庫的應用,主要是經常使用的一些庫,array,bind,function,regex,thread,unordered,ref,smartpointers庫,晚上看了看設計模式。

機房重構】總結

方法調用 什麽 是個 協調 自己 ont 之間 過程 不能 機房收費個人版算是磕磕絆絆完畢了,這裏話不多說,收獲的東西,遇到的困難。僅僅有自己才幹懂得。總結一下重構過程中的問題。不足及學到的東西。 一.驗收問題 那天緊趕慢趕的完畢及功能實現,就想著急的找

facade外觀模式

creat ack this 通過 toc 遺留代碼 定義 拓展 create 通過買股票與通過基金買股票引出外觀模式: package com.disign.facade; /** * Created by zhen on 2017-05-18. */ pub

適配器和外觀模式

在外 適配 player 維護成本 ide volume src 成本 current 一、 基本概述 1:現實中存在三角插頭適配成雙插頭,等其他各種形式的適配器來連接不兼容的兩個物體。同理在代碼中也存在適配器模式來兼容兩個不同的代碼接口。 2:KTV包間打開一個啟動開

設計模式外觀模式

設計模式 外觀模式 facade 門面模式 1、外觀模式的簡單介紹(也叫門面模式): a、外觀模式和迪米特法則(最少知識的原則,一個軟件實體應當盡可能少的與其他實體發生相互作用)的聯系緊密。 b、外觀模式的核心: - 為子系統提供統一的入口。封裝子系統的復雜性,便於