想象一下，你正在寫一個Solidity智能合約，其中一個屬性可以被描述為類型或狀態(tài)。換句話說，來自一組有限的選項。你馬上對自己說：“太好了，我只會使用枚舉類型來表示這個狀態(tài)變量。”一方面，這種方法有一些好處，比如增加可讀性。另一方面，它很容易讓你走上一條可能導致問題的棘手道路。

好吧，如果枚舉（ENUM）成員僅封裝在一個合約中并且從未在其他文件中提及過，那么一切都可以。 然而DAPP通常由幾個相互連接的合約組成。當相同的枚舉（ENUM）出現(xiàn)時，我要討論的問題會出現(xiàn)：

1. 枚舉成員出現(xiàn)在多個合約中

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函數(shù)可以更改用戶的狀態(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ū)塊鏈。

一切都很好：你調(diào)用changeStateA或changeStateB，并通過自己的setState函數(shù)相應地修改存儲合約的數(shù)據(jù)。 但是有一天你意識到你需要一個全新的狀態(tài)選項來實現(xiàn)一些全新的功能。你稱之為Statec（哇！多好的名字?。。?。首先，通過在IStorage中添加新的枚舉成員來修改源代碼…

enum RecordState {StateA， StateB， StateC}

和StorageUser的新方法。

function changeStateC（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateC）;

}

此外，作為一個負責任的開發(fā)人員，您編寫調(diào)用新方法的測試并報告成功。您的計劃是僅重新部署StorageUser合同，并且您不希望重新部署存儲，因此很多重要數(shù)據(jù)都采用映射形式，很難遷移。因此，StorageUser將使用當前存儲作為其構造函數(shù)參數(shù)進行重新部署。你調(diào)用新的changeStateC函數(shù)。..。..它失敗了。

失敗的根源

你看，更新后的StorageUser知道RecordState枚舉的3個成員，但舊的Storage沒有關于新的StateC選項的線索。它無法將setState函數(shù)參數(shù)StateC轉換為其枚舉版本，因此失敗。

更重要的是，您的測試可能會欺騙您，因為他們使用了兩個合約的更新版本。

實際上，你甚至可以在官方文件中看到關于這個問題的警告。從整數(shù)顯式轉換在運行時檢查該值是否在枚舉范圍內(nèi)，否則將導致失敗的斷言。

要吸取的教訓

首先，在如上所述的情況下，用普通整數(shù)替換枚舉更好。是的，它們看起來不那么好但結果結構更可靠和可擴展。

其次，不要拋棄使用枚舉字段的整個想法。 如果這樣的領域只在一個合約內(nèi)，那絕對是安全的。 如果您可以確保在修改的情況下完全重新部署使用枚舉的所有合約，這也是安全的。 請記住，當枚舉首次從IStorage導入到StorageUser合約時出現(xiàn)問題，并且只有在修改初始成員后才重新部署后者。

只是不要忘記，如果你真的想在合約中使用枚舉，最好三思而后行。
來源；區(qū)塊鏈研究實驗室?