【開發智能合約 — Solidity系列】實作篇Ep.13 — 抽象化的合約(Abstract Contracts)

更新於 發佈於 閱讀時間約 3 分鐘
我們在前幾篇有介紹到介面的用途,都知道介面可以制定規格,建議可以先複習一下這一篇「【開發智能合約 — Solidity系列】實作篇Ep.10 — 標準化的介面(Interfaces)」,而這次來介紹一個非常抽象的概念,名為「抽象化合約」,果然如其名! 不太容易理解,這種合約跟介面非常相似,都可以用來制定規格,而不同之處在於「抽象合約」可以被繼承,且「抽象合約」可以實作一些共同方法,但介面是不能實作的,也就是說介面有點設計的意味在,以「車」為例,介面僅設計出草圖,後續交由各種汽車、卡車…,進行不同的實作,只要遵照著規格走就好,怎麼實作就由各家決定,但「抽象合約」還可以先設計出「驅動」的方法,並藉由繼承的方式讓不同的車種皆擁有一樣的「驅動」方式,具有減少共同實作邏輯的特性。

以介面來實現,功能雖廣泛,但…

舉例來說,我們可能會設計一個「車」的介面,這個介面規格規定必須有「驅動」的功能,以燃油車來說會去實作「車」的介面,除了具備「驅動」以外,我們在燃油車的類別還可以實作「添加燃油」的功能,以符合燃油車的特性,那麼假設要製造其他燃油車型時,我們只要繼承「燃油車」這個類別就能基於燃油車進行擴充,以solidity語法設計如下:
// 車的介面
interface ICar {
// 驅動
function drive() external;
}// 燃油車
contract FuelCar is ICar {
// 實作燃油車的驅動方式
function drive() public override {
...
} // 添加燃油
function fill() public {
...
}
}// 一般燃油轎車
contract GeneralCar is FuelCar {
...更多燃油車的方法
}
但…,有沒有發現,這樣的方式雖然非常直觀,但也帶來了層層實作繼承的複雜度與設計規劃的高水準。

我們用抽象合約來實現看看?

我們可以發現到,捨去介面後會由三層降為兩層,主要是因為抽象合約除了可以制定規格以外,也能實現共同方法,讓繼承的類別除了自行實作之外,亦可承襲共同方法。
abstract contract FuelCar {
// 定義驅動的方法,讓繼承類別各自實作
function drive() public virtual; function fill(uint amount) public {
// 添加燃油...
}
}// 一般燃油轎車
contract Car is FuelCar {
function drive() public override {
// 實作一般燃油轎車的驅動方法
}
}
除了能夠操作實作的「驅動」之外,亦可操作到繼承的添加函數。

結語

一開始在看介面與抽象類別時真的是傻傻分不清楚,兩者實在太相似了,因此有些程式語言就乾脆移除抽象類別的使用方式,但又會有別的派系支持抽象類別的使用,才會發現到市面上各種程式語言皆提倡不同的理念,有的程式語言甚至乾脆移除抽象類別的使用情境,例如: Golang…等,對我們來說多學一個念也無彷拉,只要知道其中的核心理念即可得心應手。
為什麼會看到廣告
avatar-img
119會員
268內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
阿Han的沙龍 的其他內容
我們上一篇有介紹了「【開發智能合約 — Solidity系列】實作篇Ep.11 — 繼承同源但不同意圖的函數覆寫(Function Overriding)」學習到overriding這個關鍵字的概念,而今天介紹另一個非常相似的名詞overloading(超載),兩者看似很像,但本質上卻存在著非常大的
我們在「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」有提到繼承的一些基本概念,然而在繼承的過程中我們可能會用到上游的方法,甚至加工,而方法名稱重複了,是否能被允許呢? 答案是「允許」的,就好比我們雖然繼承了父親的「處事技巧」,但在求新求變的時代中
在講Gas這個概念之前,我們先以汽車為例子,不論是上高速公路還是加油,都是需要費用的,而費用的計算方式也跟我們使用的資源多寡有關,因此整個Gas就是圍繞在使用者付費的基礎之上,而計價的依據則根據Gas Price、Gas Limit最終產生出Gas fee。 相信對於Gas具備基本概念之後,我們在開
Interface我們就將之想像成是一種標準化的規範,在產品還沒開發出來之前,我們心中想必已經有個藍圖,嗯…,這個功能需要什麼樣的功能,這時候就可以來制定介面,以「設計」為出發點而後再進入「實作」,如此一來我們在設計階段就能發現一些盲點,減少經過實作過程才發現的窘境,節省繁複修改的成本,而且介面定義
一個功能越趨完善且複雜的合約,勢必會拆成許多合約共同組成,而其實這些組成的合約之中許多的方法、元素都是重複的,因此我們可以使用Inheritance(繼承)的技巧,將共同的屬性、方法抽到某個上級合約,而其餘的合約只要繼承自上級合約,就能減少重複開發的狀況,我們都知道軟體開發的過程,只要開發的原始碼越
Solidity支援兩種特殊的函數,分別是Fallback以及Receive,一個是處理合約中不存在的功能時進行的回退機制,而另一個Receive則是負責收款後的動作,但兩者稱為特殊函數的原因主要是跟我們一般函數不同的地方於它們是屬於匿名的函數,也就是不用給定Function名稱,因此才會較為特殊,
我們上一篇有介紹了「【開發智能合約 — Solidity系列】實作篇Ep.11 — 繼承同源但不同意圖的函數覆寫(Function Overriding)」學習到overriding這個關鍵字的概念,而今天介紹另一個非常相似的名詞overloading(超載),兩者看似很像,但本質上卻存在著非常大的
我們在「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」有提到繼承的一些基本概念,然而在繼承的過程中我們可能會用到上游的方法,甚至加工,而方法名稱重複了,是否能被允許呢? 答案是「允許」的,就好比我們雖然繼承了父親的「處事技巧」,但在求新求變的時代中
在講Gas這個概念之前,我們先以汽車為例子,不論是上高速公路還是加油,都是需要費用的,而費用的計算方式也跟我們使用的資源多寡有關,因此整個Gas就是圍繞在使用者付費的基礎之上,而計價的依據則根據Gas Price、Gas Limit最終產生出Gas fee。 相信對於Gas具備基本概念之後,我們在開
Interface我們就將之想像成是一種標準化的規範,在產品還沒開發出來之前,我們心中想必已經有個藍圖,嗯…,這個功能需要什麼樣的功能,這時候就可以來制定介面,以「設計」為出發點而後再進入「實作」,如此一來我們在設計階段就能發現一些盲點,減少經過實作過程才發現的窘境,節省繁複修改的成本,而且介面定義
一個功能越趨完善且複雜的合約,勢必會拆成許多合約共同組成,而其實這些組成的合約之中許多的方法、元素都是重複的,因此我們可以使用Inheritance(繼承)的技巧,將共同的屬性、方法抽到某個上級合約,而其餘的合約只要繼承自上級合約,就能減少重複開發的狀況,我們都知道軟體開發的過程,只要開發的原始碼越
Solidity支援兩種特殊的函數,分別是Fallback以及Receive,一個是處理合約中不存在的功能時進行的回退機制,而另一個Receive則是負責收款後的動作,但兩者稱為特殊函數的原因主要是跟我們一般函數不同的地方於它們是屬於匿名的函數,也就是不用給定Function名稱,因此才會較為特殊,
你可能也想看
Google News 追蹤
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
※ class類別 什麼是class? class是創造consturctor function時的語法糖,本質上與使用function創造物件(object)的行為沒有不同。 class的作用: 用來定義、描述要創造的物件(object)具有那些屬性、行為的一個表達式。就像是「車子的設計圖
Thumbnail
通用汽車和本田合作開發氫燃料電池供商用車輛和重型工具使用的新技術。這種氫燃料電池可用於商用卡車、重型裝置和發電機,並可能成為未來長途卡車運輸和發電的首選燃料。
Thumbnail
什麼是一份好的契約,是個長篇大論,因為那會涉及到許多結合個案的判斷因素,但至少我們可以從一些很多契約都會出現的條文來判斷,這份契約是不是有花心思設計過的。我們在這個主題分享,會列出許多可能你常見的契約條文,看似很棒很有保障,但只要稍微舉例,就會細思極恐,發現那根本發揮不了效用
延續上一篇關於競爭的關係,從另外一個面向來思考說明。競爭代表的是因為有東西相同,佔據到同樣的位置,所以才會產生競爭,只是是什麼東西相同呢? 1.競爭名詞:講到特定的名詞,如講到車子、化妝品,想要佔據相同名詞的人就會產生競爭。而為了避免競爭,或是劃分競爭場域,我們也可以將名詞往下切分,如:休旅車、轎
類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
Thumbnail
法律主要缺點就是模糊與不確定,卻也成其最大的優點,因為具有靈活和適應程度的契約規則。智能合約主要優點就是自主保證執行,卻構成其最大的限制,導致過度僵化和無法持續與環境同步。只有時間才能證明區塊鏈技術及是否會真正轉變且滲入我們的世界,也就是Web3世界的到來。而我相信智能法律合約將會是未來的發展趨勢!
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
※ class類別 什麼是class? class是創造consturctor function時的語法糖,本質上與使用function創造物件(object)的行為沒有不同。 class的作用: 用來定義、描述要創造的物件(object)具有那些屬性、行為的一個表達式。就像是「車子的設計圖
Thumbnail
通用汽車和本田合作開發氫燃料電池供商用車輛和重型工具使用的新技術。這種氫燃料電池可用於商用卡車、重型裝置和發電機,並可能成為未來長途卡車運輸和發電的首選燃料。
Thumbnail
什麼是一份好的契約,是個長篇大論,因為那會涉及到許多結合個案的判斷因素,但至少我們可以從一些很多契約都會出現的條文來判斷,這份契約是不是有花心思設計過的。我們在這個主題分享,會列出許多可能你常見的契約條文,看似很棒很有保障,但只要稍微舉例,就會細思極恐,發現那根本發揮不了效用
延續上一篇關於競爭的關係,從另外一個面向來思考說明。競爭代表的是因為有東西相同,佔據到同樣的位置,所以才會產生競爭,只是是什麼東西相同呢? 1.競爭名詞:講到特定的名詞,如講到車子、化妝品,想要佔據相同名詞的人就會產生競爭。而為了避免競爭,或是劃分競爭場域,我們也可以將名詞往下切分,如:休旅車、轎
類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
Thumbnail
法律主要缺點就是模糊與不確定,卻也成其最大的優點,因為具有靈活和適應程度的契約規則。智能合約主要優點就是自主保證執行,卻構成其最大的限制,導致過度僵化和無法持續與環境同步。只有時間才能證明區塊鏈技術及是否會真正轉變且滲入我們的世界,也就是Web3世界的到來。而我相信智能法律合約將會是未來的發展趨勢!