🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

【圖解】RPG中攻略物件導向的真相

如標題所示,這次我們將探討物件導向。
我大學時候念的是資訊相關科系,四年級時研究室每周都有使用Smalltalk的物件導向課程。那位教授非常有趣,不僅講程式,還會從日常生活中不斷引入物件導向的例子,讓我也陶醉於這樣的習慣之中。
然而,這種習慣意外地對提升生活品質有幫助……希望大家也能與我一樣養成這樣的習慣。(一旦習慣後,程式設計的視角會逐漸融入日常生活,強烈推薦!)
我認為這是我們工程師不能避開的道路,希望大家也能發掘出來。

0.前言

當我初次接觸物件導向時,遇到的障礙主要有以下幾點:

  • 從程序式程式設計(自上而下寫程式碼)轉變為物件導向程式設計(根據物件定義模型和程序)
  • Java、Python、Ruby、TypeScript等語言的建構子寫法及概念各有不同

這些是周圍不少人培訓時遇到的障礙。
不過,我個人認為透過「將程式視為現實世界中的物品(物件)」來整理思路,理解會有所進展。如果大家也有可以這樣比喻的意見,歡迎留言告訴我。
這次我將以RPG角色創建為例,來探討不論使用哪種語言都能一致運用的「四大原則」,希望能以視覺化的方式讓大家理解。

1. 類別與實體:設計圖與具體物

首先是所有基礎的概念。
類別是 「定義共同規則和項目的設計圖」
實體則是具體的類別化身。
當大家向別人解釋事情時,常常會先介紹抽象的概念。
如果對方似乎能理解,會接著加上 「例如」這個用語,然後提出具體的案例。那個「具體的案例」的提出過程,正是物件導向中的「實體化」的近似意象。

用RPG角色來比喻如下:

  • 類別
    類別

  • 實體
    實體

 // kotlin程式碼示例
 val hero = Warrior("阿爾斯", hp=120, strength=85)
 val knight = Warrior("希爾瓦", hp=180, strength=60)
 val boss = Warrior("達克隆", hp=500, strength=200)
 hero.attack() // 可以呼叫相同的方法
 boss.attack() // 不過因為strength不同,結果也會不同

2. 封裝:保護資料的防護牆

物件導向的重要防護要素,便是 「封裝」
封裝

為何需要防護牆?

如果角色的「HP」這個重要數據,任何人都可以從任何地方將其改為 HP = 0,那麼遊戲平衡很快就會崩潰。(這就是作弊…)

  • 防護牆內部(資料)

    • 棒人(角色)及其屬性(HP等)。
  • 防護牆表面(方法)

    • 如「受到傷害」「恢復」等公開的按鈕。

封裝的本質

  • 隱藏資料(棒人)在防護牆內部。
  • 只有透過預設的按鈕(方法),內部才能安全處理。
    這便是封裝的真正意義。

3. 繼承:透過金字塔重複利用「基本功能」

要有效增加角色的變化,知識在於 「繼承」
繼承

只需創造差異性即可

從頭開始創建「魔法師」或「戰士」是相當艱難的。因此,我們創建一個共同的「角色」父類別。

  • 金字塔頂端(父類別:Character)

    • 所有角色共通的「名稱」「HP」「行走」等性質。
  • 金字塔下層(子類別:Wizard / Warrior)

    • 100%繼承父類的功能。
    • 同時,添加屬於自己的「魔法」或「劍技」。

繼承的優點

  • 隨著金字塔的下降,功能變得越來越具體。
  • 「父類別能做的事情,子類別當然也能做到」的狀態。
    由此能大幅減少開發中的重複工作(二度手間)。

專欄:繼承與聚合的區別
雖然這次不會詳細說明,但在物件間的關係中,還有一個概念是 聚合。繼承與聚合可以如下區分。

繼承(Inheritance)
「A是B的一種類型(Is-a關係)」,就像人類或魔族。

聚合(Aggregation)
「A擁有B(Has-a關係)」,就像可拆卸的裝備一樣。
(例:劍士持有劍,魔法師持有魔法杖)

若想讓「戰士」擁有「劍」功能的話,若錯誤地使用了「繼承」……
class 戰士 extends 劍 (戰士是劍的一種),就會產生不明人類或武器的奇妙結構。
而若使用「聚合」,只需在戰士的物件中持有「劍物件」即可。

4. 多態性:相同指令下的不同行為

最後,透過相同的「攻擊」指令,讓角色展現各自的個性,這個機制便是 「多態性(Polymorphism)」
試著想像一下給全體隊伍發出 attack()(攻擊)的指令的場景。

  • 劍士:Warrior 用劍進行斬擊。
  • 魔法師:Wizard 揮動杖發射火焰。
  • 格鬥家:Fighter 進行拳擊。

為何這樣的設置令人愉快?

  • 呼叫的名稱(方法名)相同。
  • 但,根據接受者(實體)自動切換到適當的行為
  • 即使新增職業,發出指令的一方(主程式)只需簡單地說「大家,攻擊!」即可。

總結:語言變化也不改「圖」

大家覺得怎麼樣?

  • 類別是設計圖,實體是具體物。
  • 封裝是防止隨意更改狀態的防護牆。
  • 繼承是金字塔結構中重複利用功能。
  • 多態性是用相同指令讓角色展現個性。

首先,請珍惜這些視覺化,開始寫程式吧!
同時,試著將周遭事物想象為這是類別…這是實體…也許會很有趣。

專欄:為何要學習「範式」
這是我的看法,儘管編程的語言文法各異,
但是,不論是哪種語言,理解物件導向的範式與否對語言學習的效率會有很大的影響。

僅僅記住文法像是「記單字」,而理解範式則像是「安裝思維的作業系統」。一旦安裝了這個OS,即使遇到新的語言,也能以「這個語言該如何表達?」的視角,驚人地順利掌握。


原文出處:https://qiita.com/renly/items/d6a7f12c2a472bef58bf


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝26   💬2  
771
🥈
我愛JS
💬5  
16
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付