【開發智能合約 — Solidity系列】實作篇Ep.12 — 合約內同名但不同用途的函數超載

更新於 發佈於 閱讀時間約 5 分鐘
我們上一篇有介紹了「【開發智能合約 — Solidity系列】實作篇Ep.11 — 繼承同源但不同意圖的函數覆寫(Function Overriding)」學習到overriding這個關鍵字的概念,而今天介紹另一個非常相似的名詞overloading(超載),兩者看似很像,但本質上卻存在著非常大的差異,究竟要如何分辨呢?

Overriding V.S Overloading

首先是overriding的概念,override這個單詞代表著覆蓋的意思,可以理解為「覆蓋掉xxx方法」,但為什麼沒看到在同一份合約中以override形式出現呢? 試想,同一份合約覆蓋相同方法似乎沒什麼意義對吧,有點脫褲子放屁的意義,因為最終僅會保留最後一份最新的功能函數(function),因此overriding才會被應用在繼承的情境之下。
contract Parent {
/// @notice 工作
/// @dev 欲被繼承的方法應使用virtual關鍵字宣告
function doJob() public pure virtual {
...
}
}contract Child is Parent {
/// @notice 工作
/// @dev 繼承並覆寫應使用override關鍵字宣告
function doJob() public pure override {
...
}
}
再者是overloading的概念,這邊可以拆成over及loading分開來看,over代表著「超過…」的意思,而loading則是「載入更多…」,合再一起看就是「超過…就載入更多…」,因此才會有同一份合約中明明相同的函數名稱,卻允許不同的參數傳入,也實現了不同的實作方法。
contract OverloadingExample {    /// @notice 繪製單點圖
/// @dev 繪製x軸
function draw(uint x) public pure { } /// @notice 繪製平面圖
/// @dev 繪製x、y軸的平面圖
function draw(uint x, uint y) public pure { } /// @notice 繪製3D圖
/// @dev 繪製x、y、z軸的3D圖
function draw(uint x, uint y, uint z) public pure { }
}

實際Demo範例

contract OverloadingExample {
event Log(string msg); /// @notice 繪製單點圖
/// @dev 繪製x軸
function draw(uint x) public {
emit Log("draw x");
} /// @notice 繪製平面圖
/// @dev 繪製x、y軸的平面圖
function draw(uint x, uint y) public {
emit Log("draw x y");
} /// @notice 繪製3D圖
/// @dev 繪製x、y、z軸的3D圖
function draw(uint x, uint y, uint z) public {
emit Log("draw x y z");
}
}
我們一樣使用Solidity Remix Editor來進行合約的測試,如果不清楚如何進行Debug的朋友歡迎先來閱讀此篇「【開發智能合約 — Solidity系列】環境與工具篇:如何使用Remix進行Debug」,接著我們就直接進行Deploy到暫存鏈進行測試如下:

繪製單點圖

繪製2D平面圖

繪製3D圖

結語

這一次學習到Overriding與Overloading的不同之處,常常我們都被非常相似的名詞搞混,但事實上理解它們是有一套邏輯可以融會貫通的,不一定要死記名詞,而是藉由聯想的方式串通起來,Overloading非常的好用,我們一開始設計功能的時候可能只有非常陽春的功能,隨著需求的收斂,功能越趨完善,此時就能夠根據不同的參數設計出更完整個功能,也不會影響到既有的陽春功能版本,讓合約更具擴充性與相容性。
今天的範例都在這裡「📦 solidity-remix-toturial/Ep12」歡迎自行取用。
喜歡撰寫文章的你,不妨來了解一下:
歡迎加入一起練習寫作,賺取知識,累積財富!
為什麼會看到廣告
avatar-img
119會員
268內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
阿Han的沙龍 的其他內容
我們在「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」有提到繼承的一些基本概念,然而在繼承的過程中我們可能會用到上游的方法,甚至加工,而方法名稱重複了,是否能被允許呢? 答案是「允許」的,就好比我們雖然繼承了父親的「處事技巧」,但在求新求變的時代中
在講Gas這個概念之前,我們先以汽車為例子,不論是上高速公路還是加油,都是需要費用的,而費用的計算方式也跟我們使用的資源多寡有關,因此整個Gas就是圍繞在使用者付費的基礎之上,而計價的依據則根據Gas Price、Gas Limit最終產生出Gas fee。 相信對於Gas具備基本概念之後,我們在開
Interface我們就將之想像成是一種標準化的規範,在產品還沒開發出來之前,我們心中想必已經有個藍圖,嗯…,這個功能需要什麼樣的功能,這時候就可以來制定介面,以「設計」為出發點而後再進入「實作」,如此一來我們在設計階段就能發現一些盲點,減少經過實作過程才發現的窘境,節省繁複修改的成本,而且介面定義
一個功能越趨完善且複雜的合約,勢必會拆成許多合約共同組成,而其實這些組成的合約之中許多的方法、元素都是重複的,因此我們可以使用Inheritance(繼承)的技巧,將共同的屬性、方法抽到某個上級合約,而其餘的合約只要繼承自上級合約,就能減少重複開發的狀況,我們都知道軟體開發的過程,只要開發的原始碼越
Solidity支援兩種特殊的函數,分別是Fallback以及Receive,一個是處理合約中不存在的功能時進行的回退機制,而另一個Receive則是負責收款後的動作,但兩者稱為特殊函數的原因主要是跟我們一般函數不同的地方於它們是屬於匿名的函數,也就是不用給定Function名稱,因此才會較為特殊,
這次的篇章主要在介紹狀態的可變性,透過約束來限制狀態,避免隨意更改狀態導致錯誤的合約出現,如果對於Solidity開發有興趣的朋友不妨參考「📚 更多關於Solidity的文章請看這裡…」,讓我們一起動動手學習開發智能合約吧! 我們都知道狀態在智能合約中扮演著非常重要的角色,經過什麼事件之後變化為什
我們在「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」有提到繼承的一些基本概念,然而在繼承的過程中我們可能會用到上游的方法,甚至加工,而方法名稱重複了,是否能被允許呢? 答案是「允許」的,就好比我們雖然繼承了父親的「處事技巧」,但在求新求變的時代中
在講Gas這個概念之前,我們先以汽車為例子,不論是上高速公路還是加油,都是需要費用的,而費用的計算方式也跟我們使用的資源多寡有關,因此整個Gas就是圍繞在使用者付費的基礎之上,而計價的依據則根據Gas Price、Gas Limit最終產生出Gas fee。 相信對於Gas具備基本概念之後,我們在開
Interface我們就將之想像成是一種標準化的規範,在產品還沒開發出來之前,我們心中想必已經有個藍圖,嗯…,這個功能需要什麼樣的功能,這時候就可以來制定介面,以「設計」為出發點而後再進入「實作」,如此一來我們在設計階段就能發現一些盲點,減少經過實作過程才發現的窘境,節省繁複修改的成本,而且介面定義
一個功能越趨完善且複雜的合約,勢必會拆成許多合約共同組成,而其實這些組成的合約之中許多的方法、元素都是重複的,因此我們可以使用Inheritance(繼承)的技巧,將共同的屬性、方法抽到某個上級合約,而其餘的合約只要繼承自上級合約,就能減少重複開發的狀況,我們都知道軟體開發的過程,只要開發的原始碼越
Solidity支援兩種特殊的函數,分別是Fallback以及Receive,一個是處理合約中不存在的功能時進行的回退機制,而另一個Receive則是負責收款後的動作,但兩者稱為特殊函數的原因主要是跟我們一般函數不同的地方於它們是屬於匿名的函數,也就是不用給定Function名稱,因此才會較為特殊,
這次的篇章主要在介紹狀態的可變性,透過約束來限制狀態,避免隨意更改狀態導致錯誤的合約出現,如果對於Solidity開發有興趣的朋友不妨參考「📚 更多關於Solidity的文章請看這裡…」,讓我們一起動動手學習開發智能合約吧! 我們都知道狀態在智能合約中扮演著非常重要的角色,經過什麼事件之後變化為什
你可能也想看
Google News 追蹤
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
呈上篇[Python基礎]類別繼承(Inheritance) 中使用的super()並加以說明,此篇文章主要敘述使用super()有什麼好處及優點。 super():是一個內建函數,用來返回父類別的物件,以便你可以使用這個物件來呼叫父類別的方法或屬性。 這種做法的目的是在子類別中繼承並延續父類別
※ OPP第三大核心-多型 ※ 多型的基本定義: 多型是利用繼承的特性,讓不同的子類別可以實現相同的介面,但在呼叫這些介面的方法時會表現出不同的行為。這使得程式設計更具彈性和擴展性,避免了複雜的條件判斷式,同時促進了代碼的重用。 class Animal { makeSound() {
Thumbnail
※ OPP第一大核心-封裝 封裝的精神在於將「方法」、「屬性」和「邏輯」包裝在類別裡面,透過類別的實例來實現。這樣外部物件不需要了解內部的實現細節,只需要知道如何使用該類別提供的接口即可。換句話說,封裝是將內部細節隱藏起來,只暴露必要的部分給使用者。 封裝的核心概念是,使用者如果想要接觸資料,只
多型性(polymorphism)是物件導向中的一個重要概念,它指的是同一個方法或函式在不同的物件類別中可以有不同的行為。在 Python 中,多型性通常是通過繼承和方法重寫(method overriding)來實現的。 主要是為了不同資料類型的實體提供統一的介面,我們藉由下面的程式範例來多理解
※ 非同步概念總複習 為什麼要使用 Promise? 在 JavaScript 開發中,處理非同步操作是常見需求,涉及如文件讀寫、數據庫查詢或網路請求等耗時任務。傳統的回調方式可能導致代碼結構混亂,稱為「回調地獄」,難以維護和理解。 Promise 是解決這問題的方法。它是一個物件(objec
Thumbnail
在物件導向程式設計的進階階段,學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法,介面確保實現類別提供特定的方法實現,而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
Thumbnail
這篇文章將會講述虛擬(virtual)與覆蓋(override)的簡易使用方式。
類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
所謂的多型是讓一個函式或是資料結構能擁有多個不同的類型,其中上一篇文章所談的就是參數多型(parametric polymorphism),這篇文章將繼續討論特設多型(ad hoc polymorphism)。特設多型跟泛型的差別在於:泛型函式對於所有的類型只能有一種實作,而特設多型會根據類型有不同
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
呈上篇[Python基礎]類別繼承(Inheritance) 中使用的super()並加以說明,此篇文章主要敘述使用super()有什麼好處及優點。 super():是一個內建函數,用來返回父類別的物件,以便你可以使用這個物件來呼叫父類別的方法或屬性。 這種做法的目的是在子類別中繼承並延續父類別
※ OPP第三大核心-多型 ※ 多型的基本定義: 多型是利用繼承的特性,讓不同的子類別可以實現相同的介面,但在呼叫這些介面的方法時會表現出不同的行為。這使得程式設計更具彈性和擴展性,避免了複雜的條件判斷式,同時促進了代碼的重用。 class Animal { makeSound() {
Thumbnail
※ OPP第一大核心-封裝 封裝的精神在於將「方法」、「屬性」和「邏輯」包裝在類別裡面,透過類別的實例來實現。這樣外部物件不需要了解內部的實現細節,只需要知道如何使用該類別提供的接口即可。換句話說,封裝是將內部細節隱藏起來,只暴露必要的部分給使用者。 封裝的核心概念是,使用者如果想要接觸資料,只
多型性(polymorphism)是物件導向中的一個重要概念,它指的是同一個方法或函式在不同的物件類別中可以有不同的行為。在 Python 中,多型性通常是通過繼承和方法重寫(method overriding)來實現的。 主要是為了不同資料類型的實體提供統一的介面,我們藉由下面的程式範例來多理解
※ 非同步概念總複習 為什麼要使用 Promise? 在 JavaScript 開發中,處理非同步操作是常見需求,涉及如文件讀寫、數據庫查詢或網路請求等耗時任務。傳統的回調方式可能導致代碼結構混亂,稱為「回調地獄」,難以維護和理解。 Promise 是解決這問題的方法。它是一個物件(objec
Thumbnail
在物件導向程式設計的進階階段,學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法,介面確保實現類別提供特定的方法實現,而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
Thumbnail
這篇文章將會講述虛擬(virtual)與覆蓋(override)的簡易使用方式。
類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
所謂的多型是讓一個函式或是資料結構能擁有多個不同的類型,其中上一篇文章所談的就是參數多型(parametric polymorphism),這篇文章將繼續討論特設多型(ad hoc polymorphism)。特設多型跟泛型的差別在於:泛型函式對於所有的類型只能有一種實作,而特設多型會根據類型有不同