原创 一、簡單工廠

    工廠適用於生產,生產出不同的對象,這些對象都有着相同的特性,又有着各自獨特的地方。     基本結構如下:        ①、超類,或許可設計成抽象的abstract     一些公用的屬性(被子類調用)     一些公用的方法

原创 十八、中介者模式

中介者模式  中介者模式,用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯示的相互引用,從而使其耦 合鬆散,而且可以獨立的改變它們之間的交互。  該模式實現了控制集中化,把交互複雜性變爲了中介者的複雜性,這就使得中介者會比任何

原创 多線程問題,你搞得定嗎?

嘿嘿,有些標題黨了。   這兩天一直在看java多線程的相關內容,略有收穫。 基礎理論就不羅列了,網上好多。以一個問題來闡述吧: (若是剛接觸多線程的新手,建議先熟悉“生產者--消費者”的經典實現)   問題:數字1、2、3……100作循

原创 七、原型模式(深淺克隆)

 類似“影之分身術”的東西,以“鳴人”爲原型,複製1000份出來,羣毆之……  在初始化信息不發生變化的情況下,克隆是最好的辦法。既隱藏了對象創建的細節,又對性能大大的提高——不用重新初始化對象,而是動態地獲得對象運行時的狀態。 ——摘自

原创 年末的bala bala bala...

姑且當做這是我的年終總結吧,不習慣用這麼正式的字眼,隨意些、個性些挺好的。   書籍:《鳥哥的linux私房菜》、《大話設計模式》、《大話數據結構》 看過,寫了筆記,除此之外什麼都沒留下…… 以上不是什麼謙虛的說法,雖然我希望是,想起此事

原创 十七、責任鏈模式

 責任鏈模式:使多個對象都有機會處理請求,從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成 一條鏈,並沿着這條鏈傳遞該請求,直到一個對象處理它爲止。 ——摘自《大話設計模式》    Ps:責任處理類都有各自的負責區塊,以聚合的方

原创 十六、命令模式

命令模式,將一個請求封裝爲一個對象,從而使你可用不同的請求對客戶進行參數化;對請求排隊或記錄請求 日誌,以及支持可撤銷的操作。  ——摘自《大話設計模式》  Ps:“將請求封裝爲對象”的思想即是該種設計模式的精華。 基本結構如下:  ①、

原创 十二、備忘錄模式

菜鳥騎士挑戰Boss,無奈實力懸殊至飲恨而終。不過好在單挑Boss前有“存檔”,“嘿嘿,Boss,我們再來打過!”  備忘錄模式用於記錄某對象某一時刻的狀態,比如對象在該時刻的某一屬性值,便於讀取“進度”。  基本結構如下  ①、需要被記

原创 十三、組合模式

 把A和B組合在一起看成一個對象  需求中是體現部分與整體層次的結構時,以及希望用戶可以忽略組合對象與單個對象的不同,統一的使用組合 結構中的所有對象時,就應該考慮用組合模式了。 ————摘自《大話設計模式》  基本結構如下:  ①、抽象

原创 十四、單例模式

 單例模式——保證一個類僅有一個實例,並提供一個訪問它的全局訪問點。  Ps:這是我會的第一個設計模式,當時是爲應付面試死記硬背的  幾種常用的實現方式如下:  ①、餓漢式 /** * 單例模式:餓漢式實現 */ public cl

原创 尋路人

工作一年多了,不太忙,除了趕項目進度的時候,總有些閒暇時光。 我承認自己是個懶人,沒有足夠的韌性利用下班時間研究專業技術。 但和大多數北漂人士一樣,一樣的不甘於平庸。   每天朝九晚五,偶爾加班,懈怠、勞累、各種誘惑混雜着時間消磨曾經的夢

原创 五、代理模式

 羞澀男孩八戒喜歡上了鄰家女孩嫦娥,由於天性靦腆、不善言辭、性格怯懦等等優良品質的干擾,不敢去當面表 達愛意,於是請自己最好的朋友三藏代爲贈送禮物,以牽線搭橋。————這就是代理模式  代理模式:爲其它對象提供一種代理以控制對這個對象的訪

原创 十五、橋接模式

橋接模式,重點在於“分組抽象”,將兩組抽象以聚合/組合的方式聯繫在一起。這兩組抽象都可以有各自的變化 而不會相互干擾。 實現系統可能有多角度分類,每一種分類都有可能變化,那麼就把這種多角度分離出來讓它們獨立變化,減少 它們之間的耦合。——

原创 四、裝飾模式

 所謂裝飾,就是在原有物件上增加新的“零件”,使其擁有新的功能。打個比方,就像一個原本裸裝的初級劍客,裝備了寶劍、坐騎、鎧甲等裝備之後,戰鬥力暴增,完成從原來的5劍砍死一頭家養豬到一劍秒殺巨龍的華麗轉身。  裝飾模式是爲已有功能動態的添加

原创 十、建造模式

 建造者模式用於創建一些複雜對象,這些對象內部構件間的建造順序通常是穩定的,但對象內部的構建通常面臨 着複雜的變化。 ————摘自《大話設計模式》   基本結構如下:  ①、產品,想要創建的複雜對象  ②、抽象建造者  各個構件的抽象建造