前面分別介紹過 Recursive Pattern [1] 以及 Classification Pattern [2],通常在每個應用系統中,不會單獨使用一種Pattern,大多時候是需要運用多個Pattern發動組合技來處理。
以下以一個大家都熟悉的遊戲為例:
《精靈寶可夢GO》中,每個精靈都有自己的基本資料,也會有多重屬性,具備的各種能力指標各有所長。每個精靈也都有害怕遇到的屬性,因此不同屬性的精靈對戰時會有相剋表。每個精靈可以進化成能力更強的精靈。
從寶可夢圖鑑[3] 中可以看到:001 妙蛙種子 屬性是草、毒;弱點是:火、冰、飛行、超能力;可以進化到002 妙蛙草。
004 小火龍 屬性是火;可進化到005 火恐龍;006 噴火龍,而進化到噴火龍時還會多一個飛行的屬性。
依之前在Classification Pattern 學到的方式,直接可以畫出下圖,由於屬性沒有需要進一步分類,所以可以將Pokemon Category Type 忽略,實際上需要的只有三個Entity,每個Entity裡面的instance 也放在旁邊供讀者參考。
而每個精靈在對戰時,則會依對戰雙方所具備的屬性有相剋的關係,影響對戰的結果,如圖二所示。
可以解讀為:屬性和屬性之間的對戰關係,屬於Peer-to-Peer 的關係,因此可以套 Recursive Pattern, 如圖三綠色區塊。讀者可以對照圖二所列的對戰攻擊加乘數字與屬性關聯裡所放的資料內容。
最後,要處理的是精靈的進化。由於是單方向的1對1關係,可以視為1對多關係。如果還要考慮精靈之間還有其它關係的話,則乃是可以套 Recursive Pattern, 如圖四綠色區塊。
前面介紹了接觸到一個析的Domain 時,將需求拆成多個小需求,再尋找合適的Pattern 來套,可以節省很多重新設計的時間哦。
圖五為最後的完成圖,共用了一個Classification Pattern 以及 2個 Recursive Pattern.
[1] Recursive Pattern: https://www.gss.com.tw/blog/data-modeling-recursive-pattern
[2] Classification Pattern: https://www.gss.com.tw/blog/data-modeling-classification-pattern
[3] 寶可夢圖鑑:https://tw.portal-pokemon.com/play/pokedex
[4] 寶可夢相剋表: https://forum.gamer.com.tw/C.php?bsn=29659&snA=9631