引言
各位旅行者們你們好,我是小森,首先我為啥是程序員。學了技術快六年了,但一直都是斷斷續續,本身自己的條件,從2021年11月份開始下載原神,總而言之不了解一些抽卡機制導致退了并且刪除了具體賬號打算重新了解,從原神4.0開始了解抽卡機制后,徹底迷上了 ‘巴巴托斯‘’’白絲舔舔舔(個人癖好)。話說回來這個誒嘿讓人感覺不靠譜,哈哈哈 當然劇情方面來看塑造出該溜子是對他對自由之神而言無人稱霸,解放蒙德這塊地方才是最穩的 然后化身為吟游詩人 溫迪。
回到故事文章本身 米哈游這家公司技術實力還是不錯的,至少在u3d 引擎 魔改方面,佩服
話說回來設計模式起源 :是隨著面向對象語言開始流行 大家發現這個有搞頭所以三位大佬站出來一套通用的設計思想誕生,‘
’設計模式“
是由Gof三位大佬提出基于面向對象核心(封裝繼承多態)擴展 對現實生活運用到面向對象程序設計里
什么是類和對象
類:可以是被自定義 人類屬于古猿類 所謂的物語類,人以群分 人類有很多特點(在這里穿插一個情緒化內容,人有選擇,你居然選擇了原神沒必要可生氣,玩個游戲還宣泄,搞不懂這是在干什么,難道你不就是因為生活沒有希望想玩玩游戲順便社交? 若是這樣建議不玩,搞得好像游戲公司都得是仇人一樣這種人盡量遠離 并且, 還有一些玩出攻略得值得珍惜 視頻平臺該怎么說呢他也是服務業,一些人就發動亂象搞信息繭房 ,然后平臺還扶持 不作死平臺,點名某二次元一哥平臺 流量才是你的財報? 發個牢騷而已不必要代入若你在意 你也跟動不動就動手,該鋤大地的玩家就去鋤大地 ,前提是你的尊重難道選擇,劇情我看來 比某些神人電視劇好看多了 ,你要是不同意就不要往下看若你還往下看,就拉黑你 ,當然我會做成視頻 )
好了繼續 人類有很多特點(不要具體想象成把自己想象成人造人啊) ,人造物 甚至龍工智能…
當然機器人從機械臂開始發展不到十幾年精準的工業化生產,當然機械臂取代人類了嗎很明顯不能運輸還得靠人 以及制造業
對象是面向對象編程(Object-Oriented Programming, OOP)中的一個核心概念,指的是類的實例化產物。在編程中,對象將數據(屬性)和行為(方法)封裝為一個整體,具有以下特點:
-
屬性(Properties):對象包含的數據特征
- 例如:一個"汽車"對象可能具有品牌、顏色、最高時速等屬性
- 屬性可以是基本數據類型(整數、字符串等)或其他對象
-
方法(Methods):對象能執行的操作
- 例如:"汽車"對象可能有啟動、加速、剎車等方法
- 方法定義了對象的行為和功能
-
封裝性(Encapsulation):
- 對象對外隱藏內部實現細節
- 通過定義公共接口(public interface)來與外界交互
- 例如:用戶只需知道如何調用"啟動"方法,無需了解引擎如何工作
-
實際應用場景:
- 在電商系統中:"訂單"對象包含訂單號、商品列表、總價等屬性,以及計算總價、生成發票等方法
- 在游戲開發中:"玩家"對象包含生命值、位置等屬性,以及移動、攻擊等方法
對象是構建復雜軟件系統的基礎單元,通過對象間的交互和組合,可以實現更高級的功能和業務邏輯。
面向對象編程(OOP)是一種程序設計范式,它以"對象"為核心,將數據和操作數據的方法組織在一起。讓我們詳細回顧面向對象的三大基本特性:
-
封裝(相當于黑盒子)
- 具體表現:將數據和操作數據的方法捆綁在一起
- 實現方式:通過訪問修飾符(public/private/protected)控制訪問級別
- 實際應用示例:
- 銀行賬戶類:隱藏余額具體數值,只提供存/取款接口
- 汽車類:隱藏發動機內部構造,只提供啟動/加速接口
- 優勢:提高安全性,降低耦合度,便于維護
-
繼承(代碼復用機制)
- 具體表現:子類繼承父類的屬性和方法
- 實現方式:extends關鍵字
- 實際應用示例:
- 圖形類作為父類,圓形/矩形類繼承
- 動物類作為父類,貓/狗類繼承
- 優勢:減少重復代碼,提高可擴展性
-
多態(同一接口不同實現)
- 具體表現:父類引用指向子類對象
- 實現方式:方法重寫(Override)和接口實現
- 實際應用示例:
- 圖形類定義draw()方法,不同子類實現不同繪制方式
- 支付接口,不同支付方式實現不同支付邏輯
- 優勢:提高程序靈活性,增強可維護性
其他重要概念:
- 抽象類:包含抽象方法的類,不能被實例化
- 接口:完全抽象的類,只包含方法聲明
- 對象關系:關聯、聚合、組合等
- 設計原則:SOLID原則(單一職責、開閉原則等)
實際開發中的應用場景:
- GUI程序開發:按鈕、窗口等組件都是對象
- 游戲開發:角色、道具等都是對象
- 企業級應用:訂單、客戶等業務實體作為對象
常見面試問題擴展:
- 重載(Overload)和重寫(Override)的區別
- 抽象類和接口的使用場景
- 組合優于繼承原則的理解
- 設計模式中的面向對象應用
設計模式的起源與發展
設計模式的概念并非憑空產生,而是源于建筑學領域,后經計算機科學家的系統化整理和提煉,最終形成了我們今天所熟知的軟件設計模式體系。
建筑學領域的啟發
設計模式的概念最早可以追溯到1977年,由美國建筑師克里斯托弗·亞歷山大(Christopher Alexander)在其著作《建筑模式語言》(A Pattern Language)中提出。亞歷山大觀察到,在建筑設計中存在一些反復出現的優秀解決方案,他將其系統化為253個"模式",每個模式都描述了特定環境下的設計問題及其解決方案。
軟件工程的引入
1990年,Kent Beck和Ward Cunningham首次將模式概念引入軟件工程領域。他們發現軟件設計中同樣存在反復出現的問題和相應的優秀解決方案。這一發現為后來的軟件設計模式研究奠定了基礎。
GoF的里程碑貢獻
1994年,由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides(被稱為"四人幫"或GoF)合著的《設計模式:可復用面向對象軟件的基礎》一書出版。這本著作系統地歸納了23種經典的設計模式,將它們分為創建型、結構型和行為型三大類,并提供了統一的描述格式:
- 模式名稱:便于交流的簡短標識
- 問題:描述何時應用該模式
- 解決方案:模式的具體內容
- 效果:模式的優勢和可能的缺點
后續發展
GoF的模式體系成為基礎后,設計模式研究持續發展:
- 領域擴展:陸續出現了并發模式、企業應用模式、分布式系統模式等
- 模式語言:形成了更系統化的模式分類和關系描述
- 反模式:研究常見的不良設計實踐及其解決方案
- 現代應用:在新興技術領域如微服務、云計算中繼續演化
設計模式的意義
設計模式的價值主要體現在:
- 共享詞匯:為開發者提供統一的交流語言
- 經驗復用:避免重復造輪子,繼承優秀設計經驗
- 設計指導:為解決特定問題提供經過驗證的方案
- 文檔工具:提高系統設計的可理解性和可維護性
設計模式不是一成不變的教條,而是需要根據具體場景靈活運用的工具。隨著軟件開發實踐的演進,設計模式體系也在不斷豐富和發展。