一、概述
遊戲開發中，會使用到很多配置檔案。適當的利用配置檔案，可以有效實現程式設計的靈活性，避免對程式功能的不斷修改，降低程式開發人員與策劃人員之間的溝通成本，提高效率。對策劃人員來說，也可以方便的進行數值測試，以達到設計目的。
二、問題
但隨著專案的推進，配置檔案的數量以及需要配置的專案越來越多，維護變得越來越困難，出錯機率就會增加。當然，通過自動化配置、自動容錯檢查等方法可以最大限度地降低人工配置量，防止出錯，但對於不便實現自動化配置的檔案以及配置檔案數太多時還是存在未知的風險，俗話說物極必反，事物總有兩面性，在享受配置檔案給我們帶來的好處時，也需要考慮可能會產生的問題，無節制的使用配置檔案終究會帶來不可控的結果。另外乙個方面，配置專案的增多，通常意味著程式中更多的邏輯處理，會增加程式的複雜性，不易於理解，也容易導致程式bug
。因此，對哪些內容可以進行配置，哪些內容不必要進行配置，我們需要權衡利弊，仔細斟酌，做出正確選擇。
其實寫這篇文章，是因為最近在專案中遇到的乙個問題，下面的討論也會從這個問題出發，通過對該功能的討論，闡述我對配置檔案的一些看法。
需求場景：設計遊戲中的buff
系統，buff
可以導致改變角色某些狀態的持續效果，其處理系統包含了三個方面的功能。第乙個是
buff
的基礎配置，第二個是
buff
的生成，第三個是
buff
的生效。要求從技能或者**上都可以配置這些
buff
，攻擊時產生相應的效果，只要實現了
buff
的模組化，就可以方便地將之配置在任何地方。
這裡為方便討論，只列舉三個異常狀態
石化：攻擊時，有一定概率使敵人進入石化狀態，石化，見文知意，會讓敵人做不出任何動作，解除時會造成一定傷害
破甲：攻擊時，有一定概率使敵人進入破甲狀態，破甲指隨機脫掉對手一件防具
詛咒：攻擊時，有一定概率使敵人進入詛咒狀態，會減少敵人的力量，智力屬性
下面介紹專案中當前的buff
基礎配置：
buff:
id: buffid
kind：效果種類（
1-增益效果
2-減益效果）
type：型別（
1-持續作用
2-每間隔一段時間作用一次）
targets：
buff
預設作用目標（可用值：
1-被技能擊中的物件
2-自己
; 格式：多種物件使用逗號分割）
covertype：可覆蓋型別（可用值：
0-不能覆蓋
>0-
可覆蓋相同值的
buff）
movelimit：是否限制移動（
0-否
1-是）
attacklimit：是否限制攻擊（
0-否
1-是）
facelimit：是否限制朝向（
0-否
1-是）
hitlimit：是否限制被擊動作（
0-否
1-是）
level
id：等級
duration：基礎持續時間
procs：基礎觸發機率
superimpose：是否有傷害疊加效果（可用值：
0-否
1-是）
interval：型別為
2時的間隔時間（單位：毫秒）
attack：基礎攻擊力
value: 配置影響的屬性值（比如力量加多少）
refreshduration：是否重新整理持續時間（
superimpose
設定為1
時，此屬性無效）
上述配置十分高大上，幾乎列出了關於buff
的所有基礎屬性，一看非常全面，只要程式設計人員正確的處理了上面所有的配置項，策劃人員就可以按既定規則隨意配置，但這只是乙個理想化的設想，很難達到設計者的目的：
a、配置項多，增加了使用者的理解難度，提高了時間成本（特別對初次使用這個配置表的人來說，看到這麼多配置項，難道不會感覺痛苦？）
b、不利於擴充套件。如果加入新的buff
型別，有可能會增加新的配置項，即使其他
buff
並不需要這個配置項。增加新配置項也意味著有可能影響到原來的
buff
型別的功能，不利於程式的穩定。
c、不利於物件導向的程式設計。我覺得最大的問題也在此，雖然從需求出發存在三種不同型別的buff
，但對系統來說，卻只是在無差別的處理一種
buff
，它們的不同只是通過冰冷的
id以及其他配置項的不同值來體現，對這些配置項的處理是一種面向過程的方式而不是物件導向（對乙個大型系統，我認為物件導向的處理方式當然是要佔絕對優勢的，我們可以腦補一下那種函式式的、面向過程的，一大堆
if...else...
語句所帶來的抓狂）
說到物件導向的程式設計，這個概念對it
行業的人來說，應該是耳熟能詳了，但真正的把這個思想運用到實際的專案開發中的人，恐怕不算太多吧（包括我在內，也不是任何時候都會想到這個概念），其實很多時候，我們如果從物件的角度來看待程式，事情就會變得簡單得多，程式不再是乾癟的一行行**，它會富有生命力，因為物件導向實際上更接近自然語言，更接近人的思維方式。
回到上面的配置上來，通過對三個buff
的功能描述，我認為可以剔除一些配置專案，下面列出簡化後的配置表：
1、對於可能需要經常調整的、數值類的配置項，應該放在配置表中。
2、對於配置一次基本不會更改的、屬於事物本身固有屬性或者特定功能的配置項，都直接寫進**實現裡，我認為將它們放在配置表中，只能帶來困惑增加理解難度。
對於這些刪除的配置項：
kind：效果種類（
1-增益效果
2-減益效果）
type：型別（
1-持續作用
2-每間隔一段時間作用一次）
targets：
buff
預設作用目標（可用值：
1-被技能擊中的物件
2-自己
; 格式：多種物件使用逗號分割）
covertype：可覆蓋型別（可用值：
0-不能覆蓋
>0-
可覆蓋相同值的
buff）
movelimit：是否限制移動（
0-否
1-是）
attacklimit：是否限制攻擊（
0-否
1-是）
facelimit：是否限制朝向（
0-否
1-是）
hitlimit：是否限制被擊動作（
0-否
1-是）
比如movelimit
，對於石化
buff
，限制角色移動本來就是這個
buff
的功能，根本沒有必要交給策劃人員去配置，也不會出現這樣的情況：此時將石化
buff
的這個屬性配置為限制角色移動，另外乙個時間卻配置為不限制角色移動，這個屬性對石化
buff
來說應該是確定的，不會隨意更改。而對其他兩個
buff
也不需要這個配置項。去除其他配置項的理由以此類推。
character：人物，角色
buffconfig：buff基礎配置資料
abstractbuffgenerator：buff生成器抽象類，因為例子中的buff有複雜的生成邏輯（buff是否可以疊加，觸發機率公式計算等），因此設計了專門的生成器來生成相應的buff，在**或者技能中直接呼叫生成器生成buff，對於沒有複雜生成邏輯的buff，也可以不用實現這個生成器，直接例項化buff即可。
abstractbuff：buff抽象類，其成員資料報括buff生成方，中buff目標方，buff生成時間，持續時間
成員方法：
onactivate()：buff開始生效時需要執行的操作，比如破甲時脫去相應裝備，詛咒時減去屬性值等，抽象類中預設實現生效時通知客戶端的操作
onexpire()：buff失效時需要執行的操作，比如石化最後對角色的掉血，詛咒最後恢復相應的屬性值，破甲穿上脫去的裝備等，抽象類中預設實現失效時通知客戶端的操作
i***pire()：判斷buff是否失效，超時時即為失效
另外還可能有間隔一段時間產生的buff效果，宣告相應的處理方法即可。
staybuff：石化buff實現類，成員資料為對角色的傷害值
cursebuff：詛咒buff實現類，成員資料為具體的減去屬性的值
breakdefendbuff：破甲buff實現類，成員資料為需要脫去的裝備
處理系統中角色的buff超時，間隔傷害等，可以單獨啟動乙個執行緒。實現上面buff的處理架構後，需要定義新的buff型別時，只需要繼承abstractbuff，在相應的方法中實現相關特性功能，很方便擴充套件，也不會影響到原有buff的功能，有效避免了buff之間功能的耦合，給測試也帶來了很大便利。
Tomcat中的配置檔案
一 server.xml 元素名 屬性 解釋 server port 指定乙個埠，這個埠負責監聽關閉tomcat的請求 shutdown 指定向埠傳送的命令字串 service name 指定service的名字 connector 表示客戶端和service之間的連線 port 指定伺服器端要建立...
優化MyBatis配置檔案中的配置
之前，我們是直接將資料庫的連線配置資訊寫在了mybatis的conf.xml檔案中，如下 1 xml version 1.0 encoding utf 8 2doctype configuration public config 3.0 en 3 configuration 4 environmen...
優化MyBatis配置檔案中的配置
之前，我們是直接將資料庫的連線配置資訊寫在了mybatis的conf.xml檔案中，如下 html view plain copy print?xmlversion 1.0 encoding utf 8 configuration environments default development e...