溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
最近準備將23種設計模式用ruby和javascript兩種語言分別實現，為什么要這么做
一.公司由于代碼風格不統一造成的溝通問題而開展的全公司學設計模式。二.作為學習后筆記用。三.選擇ruby和javascript是因為我現在主要使用這兩門語言。四.作為體會各種模式的適用點。
為什么要學設計模式？這里談談自己對設計模式看法
一.設計模式本質就是屏蔽變化點。（很精辟的悟點，看設計模式最佳角度，感謝易博士）二.沒有一種設計模式是萬能的,所以談論哪種設計模式最好是無用的，沒有最好，只有剛剛好。（基于第一條）三.設計模式不是為了耍酷，而是為了方便和其他OOA程序員溝通而制定一個標準名詞和標準動作。廢話完成，進入正文
首先來看看我們UML
在軟件系統中，經常面臨著“某個對象”的創建工作，由于需求的變化，這個對象的具體實現經常面臨著劇烈的變化， 但是它卻擁有比較穩定的接口。如何應對這種變化？提供一種封裝機制來隔離出“這個易變對象”的變化， 從而保持系統中“其它依賴該對象的對象”不隨著需求的改變而改變？這就是要說的Factory Method模式了。
定義一個用戶創建對象的接口，讓子類決定實例化哪一個類。Factory Method使一個類的實例化延遲到其子類。
1.工廠類不再負責實例的具體過程，將變化的具體構造過程，交給子類來實現。 2.將到底實例哪個類，交給調用者來決定
class Car def self.factory typeName const_get(typeName).new #查詢祖先鏈，如果查到返回這個靜態值 endendclass BMW < Car def drive p "my it's BMW" endendclass Benz < Car def drive p "my it's Benz" endendvar car = car || {}car.BMW = function(){ console.log("my it's BMW")}car.Benz = function(){ console.log("my it's Benz")}car.factory= function(name){ var o = {} o.method = car[name] return o}工廠方法適合一下情景
1.具體方法沒有定義或不無法定義，需要子類來實現。2.設計時不知道到底需要實例哪個子類。3.處理大量類似實例缺點
1.依賴繼承鏈，太過復雜不好測試免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
