前言
這篇文章將會(huì)講述類(lèi)圖的基本介紹，並且詳細(xì)敘述從零開(kāi)始製作完整的類(lèi)圖流程。
類(lèi)圖
類(lèi)圖是企劃版本的程式設(shè)計(jì)，甚至有一群以 UML 為主的程式設(shè)計(jì)師，他們不負(fù)責(zé)撰寫(xiě)程式，專(zhuān)門(mén)製作 UML 的各式圖形，我在之前有撰寫(xiě)一篇文章介紹它的基本介紹及類(lèi)圖的寫(xiě)法，詳情可以參考：
一、視覺(jué)化程式邏輯
在程式設(shè)計(jì)之前先繪製 UML 圖，能協(xié)助程式設(shè)計(jì)進(jìn)行視覺(jué)化的幫助，程式有哪些變數(shù)、哪些函式，並且在開(kāi)始撰寫(xiě)之前用更低成的本與更高的效率進(jìn)行程式的規(guī)劃。
開(kāi)學(xué)後，在新的專(zhuān)案中我嘗試使用 UML 的方式進(jìn)行程式撰寫(xiě)，效果雖然沒(méi)有到很好，因?yàn)槲覀兪且?guī)劃完工能後就直接開(kāi)始撰寫(xiě)程式，不過(guò)有一個(gè)視覺(jué)化的紀(jì)錄效果依然很好。
當(dāng)我使用 UML 之後，我就能跟另一位程式用比較具體的方式去討論程式設(shè)計(jì)的內(nèi)容，哪一個(gè) class 有問(wèn)題、哪一些函式說(shuō)的不夠清楚，也能去判斷是否完成功能的實(shí)行。
二、功能需求的呈現(xiàn)
在單純的 UML 中，就能看出一個(gè)類(lèi)別的功用與職責(zé)，並且能妥善地呈現(xiàn)是否有達(dá)成物件導(dǎo)向的單一職責(zé)原則，是否疊加了許多不同的功能，還是良好的只執(zhí)行一個(gè)單一功用。
功能需求是我在撰寫(xiě)這篇文章後想到的部分，因?yàn)槲易珜?xiě)的時(shí)候習(xí)慣只列出公有函式而非私有函式，因?yàn)槲乙詾榻o其他程式有關(guān)連的部分比較重要。
這時(shí)我想到，當(dāng)初撰寫(xiě)程式時(shí)，其實(shí)為了完成單一職責(zé)，把函式細(xì)分成很多種不同的函式，這應(yīng)該可以在 UML 階段去規(guī)劃，這項(xiàng)功能可以拆分成多少私有的函式。
三、程式腳本的關(guān)聯(lián)
如果有經(jīng)歷過(guò)那種專(zhuān)案後期，應(yīng)該有不少人體驗(yàn)過(guò)太多程式碼纏繞，不知道這個(gè)程式腳本與哪一個(gè)式腳本有關(guān)聯(lián)，這個(gè)值是否會(huì)被其他值給改變，有哪些物件會(huì)控制這個(gè)程式腳本，這些資料都能一目了然。
程式之間的關(guān)聯(lián)在前期並沒(méi)有太大的影響性，因?yàn)榍捌诘某淌酱a並不會(huì)太過(guò)於複雜，然而在設(shè)計(jì)程式時(shí)，很有可能一再疊加程式碼上去，導(dǎo)致最終的程式碼過(guò)於複雜，用 UML 的輔助是很有幫助的方法。
五大流程
我目前撰寫(xiě) UML 文檔，主要預(yù)計(jì)有五個(gè)步驟，雖然我目前應(yīng)該只到第四個(gè)步驟而已，不過(guò)第五個(gè)步驟是我下一步預(yù)計(jì)要處理的內(nèi)容，所以我依然寫(xiě)進(jìn)這篇文章了。
一、廣泛列舉可能需要的遊戲需求與功能
首先，把遊戲中的「所有」功能與需求列出來(lái)，只要腦袋想到一種遊戲功能或遊戲需求，就先寫(xiě)下來(lái)，哪怕重覆也沒(méi)有關(guān)係，重覆列出腦中飄過(guò)的思維，直到腦袋一片空白為止。
基本上遊戲在這一塊會(huì)有很多可以處理的內(nèi)容，包括遊戲管理員、玩家按鍵輸入、主角行動(dòng)、敵人智能、場(chǎng)景控制等等，把腦中浮現(xiàn)出來(lái)了所有內(nèi)容都列舉出來(lái)，並繼續(xù)撰寫(xiě)其中的子功能。
二、分割程式功能，直到不可分割為止
當(dāng)我們列完所有功能，開(kāi)始繼續(xù)分割，每一寫(xiě)出來(lái)的功能，包括子項(xiàng)目，這個(gè)功能是否可以分為不同的單一職責(zé)：例如玩家移動(dòng)，玩家按下按鍵、確定方向、給予推力等等，這一連串的過(guò)程初步就能分成三個(gè)基礎(chǔ)功能。
這個(gè)動(dòng)作要持續(xù)到不可分割為止，現(xiàn)在應(yīng)該會(huì)有很多功能陳列，依照大致上的功能把類(lèi)似的項(xiàng)目放在一起，以便於下一階段的進(jìn)行。
三、合併相似的功能與需求
現(xiàn)在我們有了一群以功能分類(lèi)的項(xiàng)目，把那些相似的功能合在一起，例如玩家跳躍、玩家移動(dòng)、玩家調(diào)查都會(huì)使用到 GetAxis 來(lái)取得玩家輸入，因此可以把他們之中關(guān)於玩家輸入的部分就會(huì)合併。
當(dāng)我們把所有相似功能合併之後，我們就能用這些功能去實(shí)現(xiàn)各種不同的功能；除此之外，也適合繼續(xù)製作出其他功能，以利維護(hù)與擴(kuò)增，因?yàn)橹嵊龅筋?lèi)似功能的時(shí)候，只需要讀取這段資料即可。
四、開(kāi)始製作 Class diagram
此時(shí)就可以開(kāi)始製作比較詳細(xì)的規(guī)劃，也就是製作 Class diagram，開(kāi)始思考比較詳細(xì)的變數(shù)與函式安排，哪些是私有、公有的變數(shù)或函式，逐步規(guī)劃每一項(xiàng)前面確定好的功能。
五、排列並增加連接
最後，把這些各自獨(dú)立的類(lèi)圖連接起來(lái)，詳細(xì)可以參考我之前寫(xiě)的文章或者網(wǎng)路上提供的教學(xué)，類(lèi)圖的連接比較複雜，不過(guò)記得箭頭指向的是關(guān)聯(lián)對(duì)象，而非來(lái)源，應(yīng)該會(huì)比較好理解。
後記
這篇文章講述了我對(duì)於類(lèi)圖的理解，裡面有很多項(xiàng)目都是最近的感悟，因此可能有些簡(jiǎn)陋或潦草，不過(guò)都是屬於比較印象深刻的部分。
瓶裝雪
達(dá)人
