想象一下，你正在寫一個Solidity智能合約，其中一個屬性可以被描述為類型或狀態(tài)。換句話說，來自一組有限的選項。你馬上對自己說：“太好了，我只會使用枚舉類型來表示這個狀態(tài)變量?！币环矫妫@種方法有一些好處，比如增加可讀性。另一方面，它很容易讓你走上一條可能導致問題的棘手道路。
好吧，如果枚舉（ENUM）成員僅封裝在一個合約中并且從未在其他文件中提及過，那么一切都可以。 然而DAPP通常由幾個相互連接的合約組成。當相同的枚舉（ENUM）出現時，我要討論的問題會出現：
1. 枚舉成員出現在多個合約中
2. 在DApp生命周期中進行修改
例如您有2份合約。第一個是存儲非常重要的信息。您還聲明了一個帶有枚舉定義的接口以引用它。
contract IStorage {
enum RecordState {StateA， StateB}
function setState（address user， RecordState newState） public;
}
contract Storage is IStorage {
mapping（address=》RecordState） public states;
constructor（） public {}
funcTIon setState（address user， RecordState newState） public {
states［user］ = newState;
}
}
每個用戶的記錄都用一個包含兩個可能選項的枚舉來表示：statea和stateb。setState函數可以更改用戶的狀態(tài)。還有另一個合約，終端用戶應該與之交互（為了簡單起見，我在存儲合約中省略了訪問控制修改器）。
contract StorageUser {
IStorage public recordStorage;
constructor（IStorage _recordStorage） public {
recordStorage = _recordStorage;
}
funcTIon changeStateA（） public {
recordStorage.setState（msg.sender， IStorage.RecordState.StateA）;
}
funcTIon changeStateB（） public {
recordStorage.setState（msg.sender， IStorage.RecordState.StateB）;
}
}
然后將這些合同部署到區(qū)塊鏈。
一切都很好：你調用changeStateA或changeStateB，并通過自己的setState函數相應地修改存儲合約的數據。 但是有一天你意識到你需要一個全新的狀態(tài)選項來實現一些全新的功能。你稱之為Statec（哇！多好的名字啊?。?。首先，通過在IStorage中添加新的枚舉成員來修改源代碼…
enum RecordState {StateA， StateB， StateC}
和StorageUser的新方法。
funcTIon changeStateC（） public {
recordStorage.setState（msg.sender， IStorage.RecordState.StateC）;
}
此外，作為一個負責任的開發(fā)人員，您編寫調用新方法的測試并報告成功。您的計劃是僅重新部署StorageUser合同，并且您不希望重新部署存儲，因此很多重要數據都采用映射形式，很難遷移。因此，StorageUser將使用當前存儲作為其構造函數參數進行重新部署。你調用新的changeStateC函數。..。..它失敗了。
失敗的根源
你看，更新后的StorageUser知道RecordState枚舉的3個成員，但舊的Storage沒有關于新的StateC選項的線索。它無法將setState函數參數StateC轉換為其枚舉版本，因此失敗。
更重要的是，您的測試可能會欺騙您，因為他們使用了兩個合約的更新版本。
實際上，你甚至可以在官方文件中看到關于這個問題的警告。從整數顯式轉換在運行時檢查該值是否在枚舉范圍內，否則將導致失敗的斷言。
要吸取的教訓
首先，在如上所述的情況下，用普通整數替換枚舉更好。是的，它們看起來不那么好但結果結構更可靠和可擴展。
其次，不要拋棄使用枚舉字段的整個想法。 如果這樣的領域只在一個合約內，那絕對是安全的。 如果您可以確保在修改的情況下完全重新部署使用枚舉的所有合約，這也是安全的。 請記住，當枚舉首次從IStorage導入到StorageUser合約時出現問題，并且只有在修改初始成員后才重新部署后者。
只是不要忘記，如果你真的想在合約中使用枚舉，最好三思而后行。
來源；區(qū)塊鏈研究實驗室?
下載文檔
