【開發智能合約 — Solidity系列】實作篇Ep.7 — 狀態的可變性限制(State Mutability)

更新於 2023/05/16發佈於 2023/05/12閱讀時間約 4 分鐘

這次的篇章主要在介紹狀態的可變性，透過約束來限制狀態，避免隨意更改狀態導致錯誤的合約出現，如果對於Solidity開發有興趣的朋友不妨參考「📚 更多關於Solidity的文章請看這裡…」，讓我們一起動動手學習開發智能合約吧！

我們都知道狀態在智能合約中扮演著非常重要的角色，經過什麼事件之後變化為什麼狀態，甚至某些特定狀態是不可被修改的，又或者是某些功能開放給外部使用時，不可以讀取到合約內狀態…，都圍繞在可變與不可變之間，而Solidity也提供了幾個特定的識別字，讓我們可以在開發特定功能時，限制該功能對於可變程度的約束。

重要的約束關鍵字，分別是： pure、view，而none的部分是沒有限制的意思，故使用none表述，但官方並未具有none這個關鍵字，特此聲明。

pure

顧名思義就是非常「純」的意思，也就是我們在功能開發上一但約束為pure，就不能對狀態進行修改，甚至連窺探也不行，這種函式通常用來計算沒有任何依賴的式子，因此過程中不會改變到任何狀態，也不會依賴狀態來進行演算。

因此假設我們在pure的function內讀取或修改狀態，在編譯階段時就會被檢查出錯誤，也無法順利編譯。

contract Example {
    string private state  = "start";    function pureFunc(uint a, uint b) public pure returns(uint) {
        // ❌ 無法讀取狀態
        // assert(bytes(state).length > 0);
        // ❌ 無法修改狀態
        // state = "doing";
        return a + b;
    }
}

view

view的部分就是想像成唯讀模式，僅能讀取狀態，但不能修改狀態，因此可以藉由狀態來進行一些判斷後運算。

contract Example {
    string private state  = "start";    function viewFunc(uint a, uint b) public view returns(uint) {
        // ✔️ 可以讀取狀態
        assert(bytes(state).length > 0);
        // ❌ 無法修改狀態
        // state = "doing";
        return a + b;
    }
}

none

沒有任何約束的function，可以讀取也可以修改狀態，除非必要，否則不建議隨意修改狀態。

function func(uint a, uint b) public returns(uint) {
        // ✔️ 可以讀取狀態
        assert(bytes(state).length > 0);
        // ✔️ 無法修改狀態
        state = "doing";
        return a + b;
 }

結語

剛接觸Solidity時不免會閱讀許多大神們的程式碼，過程中發現時不時就有個pure、view，但只知道有這兩個關鍵字卻不曾想進一步去了解，直到一步步學習時，發現編譯的過程有些警告，貼心的編譯器會建議我們，當沒有進行狀態的讀取時就使用pure…，當時也沒有深究其因，就照著IDE的警告進行修正，而透過這次的深入學習之後，才發現原來pure及view的設計是有其意義的，而我們也應該瞭解限制與用法之後，才能更進一步的開發智能合約。

今天的範例都在這裡「📦 solidity-remix-toturial/Ep7」歡迎自行取用。

📚 更多關於Solidity的文章請看這裡…

喜歡撰寫文章的你，不妨來了解一下：

Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 — 為什麼要加入？

歡迎加入一起練習寫作，賺取知識，累積財富！

為什麼會看到廣告

#區塊鏈

#智能合約

#Solidity

阿Han的沙龍阿Han的軟體技術棧 💡區塊鏈

阿Han的沙龍

116會員

261內容數

哈囉，我是阿Han，是一位 👩‍💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。

留言0

查看全部

發表第一個留言支持創作者！

阿Han的沙龍的其他內容

【開發智能合約 — Solidity系列】實作篇Ep.6 -關於可視範圍(Visibility)

為什麼要特別介紹可視範圍呢？試想，假如我們的合約裡有些非常重要的內容只能侷限於合約內使用，此時就可以運用可視範圍的技巧，將某些重要的功能、狀態鎖定在合約內使用，不隨意開放給外部調用，避免汙染內部，但有些又是共用的內容及功能時，我們就可以利用公開的可視範圍讓相同的功能能夠重複使用。合約中又可以依照

#區塊鏈 #智能合約 #blockchain

【開發智能合約 — Solidity系列】實作篇Ep.5 - 錯誤處理的機制(Error Handling)

Solidity語言的錯誤檢查提供了Require()、Revert()、Assert()，這三種方便的API調用，而這三種用途分別不同，畢竟牽涉到瓦斯費的問題，因此才會與過往的程式語言有些許的差異， require()通常會被使用在輸入值的驗證檢查，因為它的特性主要是能夠退回剩餘的Gas fee，

#區塊鏈 #智能合約 #Solidity

【開發智能合約 — Solidity系列】概念篇：關於虛擬沙盒Ethereum Virtual Machine(EVM

每個產品在實驗室研發出來後，勢必會面臨到賣給客戶的階段，那麼當我們將產品移交給客戶時，意味著也要進行環境的安裝，但問題來了，每一個客戶的環境差異甚大，總不可能為了A客戶就建立一個A客戶的環境，因應B客戶就建立B客戶的環境，這樣隨著產品的銷售量增長也將連帶耗盡公司的資源，想必這不是我們所樂見的現象，當

#區塊鏈 #智能合約 #Solidity

【開發智能合約 — Solidity系列】環境與工具篇：如何使用Remix進行Debug

建議閱讀前可以先了解一下「【開發智能合約 — Solidity系列】開發環境準備」，會比較容易操作Remix來開發智能合約。 Remix IDE的Debug方式其實也類似於我們開發軟體程式過程中的Debug流程，編輯好程式碼之後，經過編譯，發佈到暫存鏈上，對每一個區塊進行Debug，過程中逐步排查出

#區塊鏈 #智能合約 #Solidity