Time of Update: 2018-12-03
關於UML中的擴充用例的定義我發現各家之言各不相同,在《UML使用者指南》中有這麼一段:用例之間的擴充關係表示基礎用例在由延伸用例間接地說明的一個位置上,隱式地合并了另一個用例的行為。基礎用例可以單獨存在,但是在一定的條件下,它的行為可以被另一個用例的行為擴充,這個基礎用例在一個被稱做它的擴充點(Extension point)的地方被擴充,可以將擴充關係理解為擴充用例把行為放入基礎用例中。(在原文中用例用用況表示,擴充用延伸表示。)
Time of Update: 2018-12-03
16.3 完整解決方案 為了讓採購單的審批次程序更加靈活,並實現採購單的鏈式傳遞和處理,Sunny公司開發人員使用職責鏈模式來實現採購單的分級審批,其基本結構16-3所示: 在圖16-3中,抽象類別Approver充當抽象處理者(抽象傳遞者),Director、VicePresident、President和Congress充當具體處理者(具體傳遞者),PurchaseRequest充當請求類。完整代碼如下所示://採購單:請求類class PurchaseRequest
Time of Update: 2018-12-03
10.4 適配器模式與橋接模式的聯用 在軟體開發中,適配器模式通常可以與橋接模式聯合使用。適配器模式可以解決兩個已有介面間不相容問題,在這種情況下被適配的類往往是一個黑盒子,有時候我們不想也不能改變這個被適配的類,也不能控制其擴充。適配器模式通常用於現有系統與第三方產品功能的整合,採用增加適配器的方式將第三方類整合到系統中。橋接模式則不同,使用者可以通過介面繼承或類繼承的方式來對系統進行擴充。
Time of Update: 2018-12-03
14.3 完整解決方案 為了節約儲存空間,提高系統效能,Sunny公司開發人員使用享元模式來設計圍棋軟體中的棋子,其基本結構14-4所示:圖14-4 圍棋棋子結構圖 在圖14-4中,IgoChessman充當抽象享元類,BlackIgoChessman和WhiteIgoChessman充當具體享元類,IgoChessmanFactory充當享元工廠類。完整代碼如下所示:import java.util.*;//圍棋棋子類:抽象享元類abstract class
Time of Update: 2018-12-03
16.4 純與不純的職責鏈模式 職責鏈模式可分為純的職責鏈模式和不純的職責鏈模式兩種: (1) 純的職責鏈模式 一個純的職責鏈模式要求一個具體處理者對象只能在兩個行為中選擇一個:要麼承擔全部責任,要麼將責任推給下家,不允許出現某一個具體處理者對象在承擔了一部分或全部責任後又將責任向下傳遞的情況。而且在純的職責鏈模式中,要求一個請求必須被某一個處理者對象所接收,不能出現某個請求未被任何一個處理者對象處理的情況。在前面的採購單審批執行個體中應用的是純的職責鏈模式。
Time of Update: 2018-12-03
如果說開閉原則是物件導向設計的目標的話,那麼依賴倒轉原則就是物件導向設計的主要實現機制之一,它是系統抽象化的具體實現。依賴倒轉原則是Robert C. Martin在1996年為“C++Reporter”所寫的專欄Engineering Notebook的第三篇,後來加入到他在2002年出版的經典著作“Agile Software Development, Principles, Patterns, and
Time of Update: 2018-12-03
1.3 設計模式有什麼用 下面我們來回答最後一個問題:設計模式到底有什麼用?簡單來說,設計模式至少有如下幾個用途: (1) 設計模式來源眾多專家的經驗和智慧,它們是從許多優秀的軟體系統中總結出的成功的、能夠實現可維護性複用的設計方案,使用這些方案將可以讓我們避免做一些重複性的工作,也許我們冥思苦想得到的一個“自以為很了不起”的設計方案其實就是某一個設計模式。在時間就是金錢的今天,設計模式無疑會為有助於我們提高開發和設計效率,但它不保證一定會提高,。 (2)
Time of Update: 2018-12-03
張紀中版《西遊記》以出乎意料的造型和雷人的台詞遭到廣大觀眾朋友的熱議,我們在此對該話題不作過多討論。但無論是哪個版本的《西遊記》,孫悟空都是其中的一號雄性主角,關於他(或它)拔毛變小猴的故事幾乎人人皆知,孫悟空可以用猴毛根據自己的形象,複製(又稱“複製”或“拷貝”)出很多跟自己長得一模一樣的“身外身”來。在設計模式中也存在一個類似的模式,可以通過一個原型對象複製出多個一模一樣的對象,該模式稱之為原型模式。7.1 大同小異的工作周報 Sunny軟體公司一直使用自行開發的一套OA
Time of Update: 2018-12-03
介面隔離原則定義如下:介面隔離原則(Interface Segregation Principle, ISP):使用多個專門的介面,而不使用單一的總介面,即用戶端不應該依賴那些它不需要的介面。
Time of Update: 2018-12-03
10.2 橋接模式概述 橋接模式是一種很實用的結構型設計模式,如果軟體系統中某個類存在兩個獨立變更維度,通過該模式可以將這兩個維度分離出來,使兩者可以獨立擴充,讓系統更加符合“單一職責原則”。與多層繼承方案不同,它將兩個獨立變更維度設計為兩個獨立的繼承等級結構,並且在抽象層建立一個抽象關聯,該關聯關係類似一條串連兩個獨立繼承結構的橋,故名橋接模式。
Time of Update: 2018-12-03
7.3 完整解決方案 Sunny公司開發人員決定使用原型模式來實現工作周報的快速建立,快速建立工作周報結構圖7-3所示:圖7-3 快速建立工作周報結構圖 在圖7-3中,WeeklyLog充當具體原型類,Object類充當抽象原型類,clone()方法為原型方法。WeeklyLog類的代碼如下所示://工作周報WeeklyLog:具體原型類,考慮到代碼的可讀性和易理解性,只列出部分與模式相關的核心代碼class WeeklyLog implements Cloneable{
Time of Update: 2018-12-03
合成複用原則又稱為組合/彙總複用原則(Composition/Aggregate Reuse Principle, CARP),其定義如下:合成複用原則(Composite Reuse Principle, CRP):盡量使用對象組合,而不是繼承來達到複用的目的。
Time of Update: 2018-12-03
對於物件導向軟體系統的設計而言,在支援可維護性的同時,提高系統的可複用性是一個至關重要的問題,如何同時提高一個軟體系統的可維護性和可複用性是物件導向設計需要解決的核心問題之一。在物件導向設計中,可維護性的複用是以設計原則為基礎的。每一個原則都蘊含一些物件導向設計的思想,可以從不同的角度提升一個軟體結構的設計水平。
Time of Update: 2018-12-03
在實際項目中有時候需要判斷輸入的值是否全為數字,然而直接用判斷數位一些函數如Val()和Isnumeric()等 對"+"號,"-"號,還有小數點不能直接過濾,下面的函數實現判斷功能,如果全為數字返回True,如果有非數字返回False。 Public Function Number_Check(ByVal str As String) As Boolean Dim i As Integer = Len(str) Dim j As Integer
Time of Update: 2018-12-03
在設計模式的教學和推廣過程中,很多企業學員和在校學生經常問我,原廠模式(包括簡單原廠模式、Factory 方法模式和抽象原廠模式)到底有什麼用,很多時候通過反射機制就可以很靈活地建立對象,為毛還要工廠?,在本文中我將圍繞建立對象和使用對象來簡單談談工廠的作用。
Time of Update: 2018-12-03
單一職責原則是最簡單的物件導向設計原則,它用於控制類的粒度大小。單一職責原則定義如下:單一職責原則(Single Responsibility Principle, SRP):一個類只負責一個功能領域中的相應職責,或者可以定義為:就一個類而言,應該只有一個引起它變化的原因。 單一職責原則告訴我們:一個類不能太“累”!在軟體系統中,一個類(大到模組,小到方法)承擔的職責越多,它被複用的可能性就越小,而且一個類承擔的職責過多,就相當於將這些職責耦合在一起,當其中一個職責變化時,
Time of Update: 2018-12-03
21.3 完整解決方案 為了實現撤銷功能,Sunny公司開發人員決定使用備忘錄模式來設計中國象棋軟體,其基本結構21-4所示: 在圖21-4中,Chessman充當原發器,ChessmanMemento充當備忘錄,MementoCaretaker充當負責人,在MementoCaretaker中定義了一個ChessmanMemento類型的對象,用於儲存備忘錄。完整代碼如下所示://象棋棋子類:原發器class Chessman {private String
Time of Update: 2018-12-03
開閉原則是物件導向的可複用設計的第一塊基石,它是最重要的物件導向設計原則。開閉原則由Bertrand Meyer於1988年提出,其定義如下:開閉原則(Open-Closed Principle, OCP):一個軟體實體應當對擴充開放,對修改關閉。即軟體實體應盡量在不修改原有代碼的情況下進行擴充。 在開閉原則的定義中,軟體實體可以指一個軟體模組、一個由多個類組成的局部結構或一個獨立的類。 任何軟體都需要面臨一個很重要的問題,即它們的需求會隨時間的推移而發生變化。
Time of Update: 2018-12-03
21.4 實現多次撤銷
Time of Update: 2018-12-03
10.3 完整解決方案 為了減少所需產生的子類數目,實現將作業系統和影像檔格式兩個維度分離,使它們可以獨立改變,Sunny公司開發人員使用橋接模式來重構跨平台映像瀏覽系統的設計,其基本結構10-5所示: 在圖10-5中,Image充當抽象類別,其子類JPGImage、PNGImage、BMPImage和GIFImage充當擴充抽象類別;ImageImp充當實作類別介面,其子類WindowsImp、LinuxImp和UnixImp充當具體實作類別。完整代碼如下所示: