淺談REST

       REST架構風格是全新的針對Web應用的開發風格,是當今世界最成功的互連網超媒體分布式系統架構,它使得人們真正理解了HTTP協議本來面貌。隨著REST架構成為主流技術,一種全新的互連網網路應用開發的思維方式開始流行。        一、REST是什麼  REST是英文Representational State Transfer的縮寫,中文翻譯為“具象狀態傳輸”,它是由Roy Thomas Fielding博士在他的論文 《Architectural Styles and the

請求寄件者與接收者解耦——命令模式(一)

       裝修新房的最後幾道工序之一是安裝插座和開關,通過開關可以控制一些電器的開啟和關閉,例如電燈或者排氣扇。在購買開關時,我們並不知道它將來到底用於控制什麼電器,也就是說,開關與電燈、排氣扇並無直接關係,一個開關在安裝之後可能用來控制電燈,也可能用來控制排氣扇或者其他電器裝置。開關與電器之間通過電線建立串連,如果開關開啟,則電線通電,電器工作;反之,開關關閉,電線斷電,電器停止工作。相同的開關可以通過不同的電線來控制不同的電器,1所示:圖1 開關與電燈、排氣扇      

抽象外觀類的單例化分析與改造

       有博友留言問“抽象外觀類是否能設計為單例類?”,為了能夠更全面地回答這個問題,並且為大家在進行物件導向系統設計和實現時提供更多思路,加深對面板模式和單例模式的理解,特寫此文。       關於面板模式的基本知識我在此就不介紹了,大家可以參考之前有關面板模式的幾篇文章。本文所使用的範例程式碼如下(此處採用一種特殊的包含@Stereotype的注釋在原始碼中標註模式角色,目的是在逆向工程產生的UML類圖中能夠自動標註模式角色,該工具已開發完畢)://@Stereotype

從招式與內功談起——設計模式概述(二)

1.2 設計模式是什麼       俗話說:站在別人的肩膀上,我們會看得更遠。設計模式的出現可以讓我們站在前人的肩膀上,通過一些成熟的設計方案來指導新項目的開發和設計,以便於我們開發出具有更好的靈活性和可擴充性,也更易於複用的軟體系統。       設計模式的一般定義如下:設計模式(Design Pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結,使用設計模式是為了可重用代碼、讓代碼更容易被他人理解並且保證代碼可靠性。     

請求寄件者與接收者解耦——命令模式(二)

3 完整解決方案       為了降低功能鍵與功能處理類之間的耦合度,讓使用者可以自訂每一個功能鍵的功能,Sunny軟體公司開發人員使用命令模式來設計“自訂功能鍵”模組,其核心結構4所示: 圖4 自訂功能鍵核心結構圖      

請求寄件者與接收者解耦——命令模式(三)

4 命令隊列的實現       有時候我們需要將多個請求排隊,當一個請求寄件者發送一個請求時,將不止一個請求接收者產生響應,這些請求接收者將逐個執行業務方法,完成對請求的處理。此時,我們可以通過命令隊列來實現。       命令隊列的實現方法有多種形式,其中最常用、靈活性最好的一種方式是增加一個CommandQueue類,由該類來負責儲存多個命令對象,而不同的命令對象可以對應不同的請求接收者,CommandQueue類的典型代碼如下所示:import java.util.*;class

請求寄件者與接收者解耦——命令模式(四)

5 撤銷操作的實現       在命令模式中,我們可以通過調用一個命令對象的execute()方法來實現對請求的處理,如果需要撤銷(Undo)請求,可通過在命令類中增加一個逆向操作來實現。擴充除了通過一個逆向操作來實現撤銷(Undo)外,還可以通過儲存對象的曆史狀態來實現撤銷,後者可使用備忘錄模式(Memento Pattern)來實現。       下面通過一個簡單的執行個體來學習如何使用命令模式實現撤銷操作:      

組件設計原則之概念篇(二)

       前三個組件設計原則關注組件的內聚,從本文開始,接下來將要介紹的三個原則更多關注組件間的耦合,其難度比前三個原則要大,我將結合一些樣本進行講解,主要參考資料仍然是Robert C.Martin的《敏捷式軟體開發 (Agile Software Development):原則、模式與實踐》(Agile Software Development: Principles, Patterns, and Practices)一書中的“Principles of Package and

請求寄件者與接收者解耦——命令模式(五)

6 請求日誌       請求日誌就是將請求的記錄儲存下來,通常以記錄檔(Log File)的形式永久儲存在電腦中。很多系統都提供了記錄檔,例如Windows記錄檔、Oracle記錄檔等,記錄檔可以記錄使用者對系統的一些操作(例如對資料的更改)。請求記錄檔可以實現很多功能,常用功能如下:       (1) “天有不測風雲”,一旦系統發生故障,記錄檔可以為系統提供一種恢複機制,在請求記錄檔中可以記錄使用者對系統的每一步操作,從而讓系統能夠順利恢複到某一個特定的狀態;       (2)

確保對象的唯一性——單例模式 (五)

3.6 單例模式總結       單例模式作為一種目標明確、結構簡單、理解容易的設計模式,在軟體開發中使用頻率相當高,在很多應用軟體和架構中都得以廣泛應用。 1.主要優點       單例模式的主要優點如下:       (1) 單例模式提供了對唯一執行個體的受控訪問。因為單例類封裝了它的唯一執行個體,所以它可以嚴格控制客戶怎樣以及何時訪問它。       (2) 由於在系統記憶體中只存在一個對象,因此可以節約系統資源,對於一些需要頻繁建立和銷毀的對象單例模式無疑可以提高系統的效能。      

請求寄件者與接收者解耦——命令模式(六)

7 宏命令       宏命令(Macro Command)又稱為組合命令,它是組合模式和命令模式聯用的產物。宏命令是一個具體命令類,它擁有一個集合屬性,在該集合中包含了對其他命令對象的引用。通常宏命令不直接與請求接收者互動,而是通過它的成員來調用接收者的方法。當調用宏命令的execute()方法時,將遞迴調用它所包含的每個成員命令的execute()方法,一個宏命令的成員可以是簡單命令,還可以繼續是宏命令。執行一個宏命令將觸發多個具體命令的執行,從而實現對命令的批處理,其結構7所示:圖7 

設計模式綜合執行個體分析之資料庫同步系統(二)

       接“設計模式綜合執行個體分析之資料庫同步系統(一)“。         3.

請求的鏈式處理——職責鏈模式(二)

16.2 職責鏈模式概述     

操作複雜物件結構——訪問者模式(二)

26.2 訪問者模式概述      訪問者模式是一種較為複雜的行為型設計模式,它包含訪問者和被訪問元素兩個主要組成部分,這些被訪問的元素通常具有不同的類型,且不同的訪問者可以對它們進行不同的訪問操作。例如處方單中的各種藥品資訊就是被訪問的元素,而劃價人員和藥房工作人員就是訪問者。訪問者模式使得使用者可以在不修改現有系統的情況下擴充系統的功能,為這些不同類型的元素增加新的操作。     

設計模式綜合執行個體分析之資料庫同步系統(三)

       接“設計模式綜合執行個體分析之資料庫同步系統(二)“。         6. 策略模式       由於表資料的同步方式有三種,分別是增量同步處理、先Delete後Insert方式、暫存資料表方式,因此可以定義一個同步策略介面DataSynStrategy,並提供三個具體實作類別:IncSynStrategy、DelAndInsSynStrategy和TempTableSynStrategy。類圖8所示:圖8 策略模式執行個體類圖      

工廠三兄弟之簡單原廠模式(一)

       原廠模式是最常用的一類建立型設計模式,通常我們所說的原廠模式是指Factory 方法模式,它也是使用頻率最高的原廠模式。本章將要學習的簡單原廠模式是Factory 方法模式的“小弟”,它不屬於GoF 23種設計模式,但在軟體開發中應用也較為頻繁,通常將它作為學習其他原廠模式的入門。此外,Factory 方法模式還有一位“大哥”——抽象原廠模式。這三種原廠模式各具特色,難度也逐個加大,在軟體開發中它們都得到了廣泛的應用,成為物件導向軟體中常用的建立對象的工具。 1 圖表庫的設計   

擴充系統功能——裝飾模式(二)

12.2 裝飾模式概述      裝飾模式可以在不改變一個對象本身功能的基礎上給對象增加額外的新行為,在現實生活中,這種情況也到處存在,例如一張照片,我們可以不改變照片本身,給它增加一個相框,使得它具有防潮的功能,而且使用者可以根據需要給它增加不同類型的相框,甚至可以在一個小相框的外面再套一個大相框。     

樹形結構的處理——組合模式(二)

11.2 組合模式概述     

撤銷功能的實現——備忘錄模式(二)

21.2 備忘錄模式概述      備忘錄模式提供了一種狀態恢複的實現機制,使得使用者可以方便地回到一個特定的曆史步驟,當新的狀態無效或者存在問題時,可以使用暫時儲存起來的備忘錄將狀態複原,當前很多軟體都提供了撤銷(Undo)操作,其中就使用了備忘錄模式。      備忘錄模式定義如下:備忘錄模式(Memento Pattern):在不破壞封裝的前提下,捕獲一個對象的內部狀態,並在該對象之外儲存這個狀態,這樣可以在以後將對象恢複到原先儲存的狀態。它是一種對象行為型模式,其別名為Token。   

組件設計原則之概念篇(三)

      最後兩個組件設計原則將會結合軟體度量來進行介紹,將引入一些軟體度量因子,對組件設計進行定量的分析與研究。 穩定依賴原則(The Stable-Dependencies Principle, SDP)Depend in the direction of stability.朝著穩定的方向進行依賴。 穩定性與依賴性      

總頁數: 61357 1 .... 18720 18721 18722 18723 18724 .... 61357 Go to: 前往

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.