原创 一、簡單工廠
工廠適用於生產,生產出不同的對象,這些對象都有着相同的特性,又有着各自獨特的地方。 基本結構如下: ①、超類,或許可設計成抽象的abstract 一些公用的屬性(被子類調用) 一些公用的方法
原创 十八、中介者模式
中介者模式 中介者模式,用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯示的相互引用,從而使其耦 合鬆散,而且可以獨立的改變它們之間的交互。 該模式實現了控制集中化,把交互複雜性變爲了中介者的複雜性,這就使得中介者會比任何
原创 多線程問題,你搞得定嗎?
嘿嘿,有些標題黨了。 這兩天一直在看java多線程的相關內容,略有收穫。 基礎理論就不羅列了,網上好多。以一個問題來闡述吧: (若是剛接觸多線程的新手,建議先熟悉“生產者--消費者”的經典實現) 問題:數字1、2、3……100作循
原创 七、原型模式(深淺克隆)
類似“影之分身術”的東西,以“鳴人”爲原型,複製1000份出來,羣毆之…… 在初始化信息不發生變化的情況下,克隆是最好的辦法。既隱藏了對象創建的細節,又對性能大大的提高——不用重新初始化對象,而是動態地獲得對象運行時的狀態。 ——摘自
原创 年末的bala bala bala...
姑且當做這是我的年終總結吧,不習慣用這麼正式的字眼,隨意些、個性些挺好的。 書籍:《鳥哥的linux私房菜》、《大話設計模式》、《大話數據結構》 看過,寫了筆記,除此之外什麼都沒留下…… 以上不是什麼謙虛的說法,雖然我希望是,想起此事
原创 十七、責任鏈模式
責任鏈模式:使多個對象都有機會處理請求,從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成 一條鏈,並沿着這條鏈傳遞該請求,直到一個對象處理它爲止。 ——摘自《大話設計模式》 Ps:責任處理類都有各自的負責區塊,以聚合的方
原创 十六、命令模式
命令模式,將一個請求封裝爲一個對象,從而使你可用不同的請求對客戶進行參數化;對請求排隊或記錄請求 日誌,以及支持可撤銷的操作。 ——摘自《大話設計模式》 Ps:“將請求封裝爲對象”的思想即是該種設計模式的精華。 基本結構如下: ①、
原创 十二、備忘錄模式
菜鳥騎士挑戰Boss,無奈實力懸殊至飲恨而終。不過好在單挑Boss前有“存檔”,“嘿嘿,Boss,我們再來打過!” 備忘錄模式用於記錄某對象某一時刻的狀態,比如對象在該時刻的某一屬性值,便於讀取“進度”。 基本結構如下 ①、需要被記
原创 十三、組合模式
把A和B組合在一起看成一個對象 需求中是體現部分與整體層次的結構時,以及希望用戶可以忽略組合對象與單個對象的不同,統一的使用組合 結構中的所有對象時,就應該考慮用組合模式了。 ————摘自《大話設計模式》 基本結構如下: ①、抽象
原创 十四、單例模式
單例模式——保證一個類僅有一個實例,並提供一個訪問它的全局訪問點。 Ps:這是我會的第一個設計模式,當時是爲應付面試死記硬背的 幾種常用的實現方式如下: ①、餓漢式 /** * 單例模式:餓漢式實現 */ public cl
原创 尋路人
工作一年多了,不太忙,除了趕項目進度的時候,總有些閒暇時光。 我承認自己是個懶人,沒有足夠的韌性利用下班時間研究專業技術。 但和大多數北漂人士一樣,一樣的不甘於平庸。 每天朝九晚五,偶爾加班,懈怠、勞累、各種誘惑混雜着時間消磨曾經的夢
原创 五、代理模式
羞澀男孩八戒喜歡上了鄰家女孩嫦娥,由於天性靦腆、不善言辭、性格怯懦等等優良品質的干擾,不敢去當面表 達愛意,於是請自己最好的朋友三藏代爲贈送禮物,以牽線搭橋。————這就是代理模式 代理模式:爲其它對象提供一種代理以控制對這個對象的訪
原创 十五、橋接模式
橋接模式,重點在於“分組抽象”,將兩組抽象以聚合/組合的方式聯繫在一起。這兩組抽象都可以有各自的變化 而不會相互干擾。 實現系統可能有多角度分類,每一種分類都有可能變化,那麼就把這種多角度分離出來讓它們獨立變化,減少 它們之間的耦合。——
原创 四、裝飾模式
所謂裝飾,就是在原有物件上增加新的“零件”,使其擁有新的功能。打個比方,就像一個原本裸裝的初級劍客,裝備了寶劍、坐騎、鎧甲等裝備之後,戰鬥力暴增,完成從原來的5劍砍死一頭家養豬到一劍秒殺巨龍的華麗轉身。 裝飾模式是爲已有功能動態的添加
原创 十、建造模式
建造者模式用於創建一些複雜對象,這些對象內部構件間的建造順序通常是穩定的,但對象內部的構建通常面臨 着複雜的變化。 ————摘自《大話設計模式》 基本結構如下: ①、產品,想要創建的複雜對象 ②、抽象建造者 各個構件的抽象建造