Time of Update: 2018-12-04
一個23設計模式的搞笑解釋 建立型模式 1、FACTORY —追MM少不了請吃飯了,麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西,雖然口味有所不同,但不管你帶MM去麥當勞或肯德基,只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產雞翅的Factory 原廠模式:客戶類和工廠類分開。消費者任何時候需要某種產品,只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時,工廠類也要做相應的修改。如:如何建立及如何向用戶端提供。 2、BUILDER —MM最愛聽的就是“我愛你”
Time of Update: 2018-12-04
設計模式--裝飾模式“裝飾模式(Decorator)”又名“封裝模式(Wrapper)”,通常用來靈活地擴充對象的功能。在此之前我們可以通過類的繼承來擴充父類的功能,但這種繼承方式缺乏靈活性,並且會導到子類數量的快速膨脹。恰當地使用裝飾模式我們會輕鬆實現在控制子類數量的基礎上,靈活地實現對象功能的擴充。裝飾模式比類的繼承更靈活。例子:1、“小豬逃命”遊戲:一隻小豬和一隻灰狼,小豬最多5條命,灰狼每咬到小豬一次,小豬就要少一條命,小豬的任務是要逃過灰狼的追咬到豬欄。在逃的過程中小豬可以吃到三種蘋
Time of Update: 2018-12-04
設計模式之――命令模式(2008-07-04
Time of Update: 2018-12-04
設計模式------備忘錄模式(Memento pattern) 一、引子 俗話說:世上難買後悔藥。所以凡事講究個“三思而後行”,但總常見有人做“痛心疾首”狀:當初我要是……。如果真的有《大話西遊》中能時光倒流的“月光寶盒”,那這世上也許會少一些傷感與後悔——當然這隻能是癡人說夢了。 但是在我們手指下的程式世界裡,卻有的後悔藥買。今天我們要講的備忘錄模式便是程式世界裡的“月光寶盒”。 二、定義與結構 備忘錄(Memento)模式又稱標記(Token)模式。GOF給備忘錄模式的定義為:
Time of Update: 2018-12-04
1
Time of Update: 2018-12-04
IT世界好比浩瀚的大海,也許每一塊都夠一個人研究一輩子的,選擇屬於自己的一畝三分地,好好耕種,讓它開花結果才是正道。 網路、電腦硬體、電腦軟體及與電腦相關的,選擇適合自己的一塊。 單單就電腦軟體開發而言,它又包括諸如遊戲開發、作業系統開發、Web開發、應用程式開發、資料庫開發/管理維護、中介軟體開發等等,還有開發之後的測試,及開發之前的架構;單就開發而言,還包括Java開發、.Net開發、C/C++開發等等。請趕快選擇適合自己的那一畝三分地吧,因為每一塊都需要很多很多的專業知識和背景知識來實現,
Time of Update: 2018-12-04
本文主要解決以下幾個問題 1 為什麼要使用庫? 2 庫的分類 3 建立自己的庫 或許大家對自己初學linux時的情形仍記憶尤新吧。如果沒有一個能較好的解決依賴關係的包管理器,在linux下安裝軟體將是一件及其痛苦的工作。你裝a包時,可能會提示你要先裝b包,當你費盡心力找到b包時,可能又會提示你要先安裝c包。我就曾被這樣的事搞的焦頭爛額,至今一提起rpm仍心有餘悸,頭皮發麻。說是一朝被蛇咬,十年怕井繩怕也不為過。
Time of Update: 2018-12-04
設計模式------中介者模式(Mediator Pattern) 一、引子 中介在現實生活中並不陌生,滿大街的房屋中介、良莠不齊的出國中介……。它們的存在是因為它們能給我們的生活帶來一些便利:租房、買房用不著各個小區裡瞎轉;出國留學也不用不知所措。中介者模式在程式設計中也起到了類似的作用。二、定義與結構GOF給中介者模式下的定義是:用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式地相互引用,從而使其耦合鬆散,而且可以獨立地改變它
Time of Update: 2018-12-04
愛國——從改變自己做起
Time of Update: 2018-12-04
本文轉自編程隨想的Blog: http://program-think.blogspot.com/2009/02/multi-process-vs-multi-thread.html 就像莎士比亞的“To be, or not to be, that is the question”始終困擾著哈姆雷特,對於“進程還是線程?”這個問題,也經常困擾著那些進行軟體架構設計的傢伙。所以今天打算聊一下我對這個問題的體會。假如你還搞不清楚線程和進程的區別,請先找本作業系統原理的書好好拜讀一下,再回來看帖。
Time of Update: 2018-12-04
<由於本文章是依據微軟的產品總結而來,僅供學習交流之用,任何商用都是被禁止的,後果自負!>在測試中,如果我們發現了產品的Defect,我們就要報Bug,那麼Bug都有哪些基本屬性呢?在微軟是這樣定義的。 對於一個Bug,以下的屬性是必須的:GeneralID - 對於每個Bug來說都是唯一的,一旦一個新Bug被File成功,那麼系統將自動產生一個獨一無二的ID。Title -
Time of Update: 2018-12-04
什麼是mock測試2008-05-31 15:09[轉]mock測試:就是在測試過程中,對於某些不容易構造或者 不容易擷取的對象,用一個虛擬對象來建立以便測試的測試方法。mock對象:這個虛擬對象就是mock對象。mock對象就是真實對象在調試期間的代替品。mock對象使用範疇:真實對象具有不可確定的行為,產生不可預測的效果,(如:股票行情,天氣預報) 真實對象很難被建立的 真實對象的某些行為很難被觸發 真實對象實際上還不存在的(和其他開發小組或者和新的硬體打交道) 等等...
Time of Update: 2018-12-04
本文轉自編程隨想的Blog: http://program-think.blogspot.com/2009/03/producer-consumer-pattern-0-overview.html 今天來介紹一下“生產者/消費者模式”,這玩意兒在很多開發領域都能派上用場。可能有同學心中犯嘀咕了:在四人幫(Gang Of Four)的23種模式裡面似乎沒聽說過這種嘛!其實GOF那經典的23種模式主要是基於OO的(從書名《Design Patterns: Elements of Reusable
Time of Update: 2018-12-04
在Automation Testing中,我們經常會在Test Case當中使用一些變數(Variables)來避免Hard Code,通常的做法是使用!變數名!或者:變數名:來表示。 例如 使用!ServerName! or :ServerName: 來表示運行Automation Test Case的那台電腦的名字。使用!DatabaseName! or :DatabaseName: 來表示資料庫的名字。使用!TestCaseName! or :TestCaseName: 來表示Test
Time of Update: 2018-12-04
python3.0與python2.x的區別 1.效能Py3.0運行pystone benchmark的速度比Py2.5慢30%。Guido認為Py3.0有極大的最佳化空間,在字串和整形操作上可以取得很好的最佳化結果。2.編碼Py3.0源碼檔案預設使用utf-8編碼,這就使得以下代碼是合法的:>>>中國 = 'china'>>>
Time of Update: 2018-12-04
本文轉自編程隨想的Blog: http://program-think.blogspot.com/2009/03/producer-consumer-pattern-1-data.html ★啥是資料單元?簡單地說,每次生產者放到緩衝區的,就是一個資料單元;每次消費者從緩衝區取出的,也是一個資料單元。對於寄信的例子,我們可以把每一封單獨的信件看成是一個資料單元。 不過光這麼介紹,太過於簡單,無助於大伙兒分析出這玩意兒。所以,後面咱們來看一下資料單元需要具備哪些特性。搞明白這些特性之後,就容易從複
Time of Update: 2018-12-04
質數,又稱素數,洋文名是Prime Number。 質數就是在所有比1大的整數中,除了1和和它本身以外,不再有別的約數,這種整數叫做質數;比1大但不是質數的數稱為合數。 1和0既非質數也非合數。 最小的質數是2。最前面的質數依次排列為:2,3,5,7,11,13,17,... ... 判斷一個數是否為質數:public bool IsPrimerNumber(int x){bool isPrimer = true;for (int i = 2; i < x; i++){if (x % i
Time of Update: 2018-12-04
訪問者模式(Visitor)定義表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。動機訪問者模式適用於資料結構相對穩定的系統,它把資料結構和作用於結構上的操作之間的耦合解脫開,使得操作集合可以相對自由地演化。目地是要把處理從資料結構分離出來。訪問者模式(Visitor)結構圖 Visitor類,為該對象結構中ConcreteElement的每一個類聲明一個Visit操作。 abstract class Visitor { p
Time of Update: 2018-12-04
現在覺得把複雜的問題說的特別簡單,真的不是一件容易的事情,關鍵是既簡單又要說明白。 對於開發任何系統,無非是做好3件事情:IPO,即Input ---> Process ---> Output. (可不是Initial Public Offering:首次公開售股) 對於軟體開發,首先要做的事情是需求分析---> 系統分析---> 系統設計 ---> 編碼 --->
Time of Update: 2018-12-04
設計模式------觀察者模式(Oberserver