【開發智能合約 — Solidity系列】實作篇Ep.10 — 標準化的介面(Interfaces)
閱讀時間約 4 分鐘
Interface我們就將之想像成是一種標準化的規範，在產品還沒開發出來之前，我們心中想必已經有個藍圖，嗯…，這個功能需要什麼樣的功能，這時候就可以來制定介面，以「設計」為出發點而後再進入「實作」，如此一來我們在設計階段就能發現一些盲點，減少經過實作過程才發現的窘境，節省繁複修改的成本，而且介面定義出來後，對於後續的分工開發就會有極大的幫助，合約之間只要照著介面完成開發最終再拼裝起來，就會是一份快速又完整的智能合約。
來看看什麼是介面
以「車」為例子，車的種類有分成卡車、轎車、救護車…，但都有一個共同點就是可以駕駛移動，而這個共同點我們就可以訂定一個標準的介面，車只是一個概念，能夠驅動，因此我們只要確保每一種車都能夠驅動即可，至於要造出什麼樣的車就是各自實作囉，以下的例子就是一個簡單的介面範例，我們先定義車能夠進行驅動的簡單介面：
// 汽車的介面
interface ICar {
/// @notice 汽車的可以進行驅動
/// @dev !!! 這邊必須以external進行可視範圍的標示，因為對於介面來說就是外部可視
function drive() external returns (string memory);
}
介面的填充實作
定義好介面之後，就是進入實作階段了，我們只要滿足「drive」這個方法即可，至於合約內部如何達成的，這不會是介面的職責，以底下的例子來說，我們會實作一台卡車，這台卡車與車本身都具有「驅動」的方法，只要能動，不管什麼類型的車，都是源於「車」。
// 汽車的介面
interface ICar {
/// @notice 汽車的可以進行驅動
/// @dev !!! 這邊必須以external進行可視範圍的標示，因為對於介面來說就是外部可視
function drive() external returns (string memory);
}contract Truck is ICar {
function drive() public pure override returns (string memory){
return "Truck";
}
}
規則
Interface的使用方式也有一些規範如下：
- 僅能被Interface繼承不能被contract繼承。
- 所有的方法在介面中僅能將可視範圍提高到external。
- 不能有建構子(constructor)。
- 不能有狀態變數(state variables)。
- 不能有功能修飾函數(modifiers)。
介面的繼承
介面的繼承其實相似於合約的繼承，關於合約的繼承，如有興趣了解的朋友請參考「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」，好吧！接著進入正題，介面的繼承範本如下，：
...interface ParentA {
function weight() external returns (uint256);
}interface ParentB {
function weight() external returns (uint256);
}interface Child is ParentA, ParentB {
function weight() external override(ParentA, ParentB) returns (uint256);
}結語
介面在軟體開發的世界裡常常被使用到，為什麼？ 主要是如果我們能夠在接收到需求進行設計時，就先定義共同會使用到哪些細節，對於未來實作時，能夠約束功能範圍之外，也減少反覆修改造成額外的開發成本，有了介面之後，我們對於產品會有更概觀的樣貌圖，也會加速需求的收斂，非常值得學習的一套技巧。
今天的範例都在這裡「📦 solidity-remix-toturial/Ep10」歡迎自行取用。
喜歡撰寫文章的你，不妨來了解一下：
歡迎加入一起練習寫作，賺取知識，累積財富！
為什麼會看到廣告
117會員
262內容數
哈囉，我是阿Han，是一位 👩💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
你可能也想看
Google News 追蹤
本章節的目的是介紹 Kotlin 中的物件導向概念。這包括了類別、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda 表達式、泛型以及反射等概念。每一個概念都會透過範例程式碼來解釋其功能和用法。
隨著Blockchain 的日益成熟，智能合約已經成為改變多個行業，包括IT服務行業的一種重要技術。智能合約不僅提高了交易的透明度，還增強了合約執行的自動化和安全性。本文將介紹智能合約的基本概念、在IT服務管理中的具體應用，以及實施時可能遇到的挑戰。
這個章節主要介紹了Swift程式語言中物件導向程式設計的基本概念，包括類別、建構子、公開、私有、受保護等等的概念。同時，也介紹了繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda表達式、泛型和反射等進階特性。
※ class類別
什麼是class？
class是創造consturctor function時的語法糖，本質上與使用function創造物件（object）的行為沒有不同。
class的作用：
用來定義、描述要創造的物件（object）具有那些屬性、行為的一個表達式。就像是「車子的設計圖
本文介紹了Python中的物件導向程式設計的重要概念，包括類別、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda表達式、泛型和反射。每個概念都有對應的程式碼範例來說明其用法和功能。這些概念對於理解和使用Python進行物件導向程式設計至關重要。
在物件導向程式設計的進階階段，學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法，介面確保實現類別提供特定的方法實現，而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
上一篇文章提到有些介面不應被繼承，但物件導向的子類別只能繼承父類別的介面，因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制，這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承，更適合使用組合，根本不需要使用繼承疊加特性。
資料類型的定義往往跟怎麼建構模型相
類似於trait/typeclass的特性系統能提供程式「延展性」，它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像，然而特性系統的彈性比較大一點，而且概念上也有一些差別。為了探討討論這些差異，我們必須深入了解繼承機制到底是什麼。
繼承並不是建立子類關係的唯一方法。所謂的
本章節的目的是介紹 Kotlin 中的物件導向概念。這包括了類別、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda 表達式、泛型以及反射等概念。每一個概念都會透過範例程式碼來解釋其功能和用法。
隨著Blockchain 的日益成熟，智能合約已經成為改變多個行業，包括IT服務行業的一種重要技術。智能合約不僅提高了交易的透明度，還增強了合約執行的自動化和安全性。本文將介紹智能合約的基本概念、在IT服務管理中的具體應用，以及實施時可能遇到的挑戰。
這個章節主要介紹了Swift程式語言中物件導向程式設計的基本概念，包括類別、建構子、公開、私有、受保護等等的概念。同時，也介紹了繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda表達式、泛型和反射等進階特性。
※ class類別
什麼是class？
class是創造consturctor function時的語法糖，本質上與使用function創造物件（object）的行為沒有不同。
class的作用：
用來定義、描述要創造的物件（object）具有那些屬性、行為的一個表達式。就像是「車子的設計圖
本文介紹了Python中的物件導向程式設計的重要概念，包括類別、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda表達式、泛型和反射。每個概念都有對應的程式碼範例來說明其用法和功能。這些概念對於理解和使用Python進行物件導向程式設計至關重要。
在物件導向程式設計的進階階段，學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法，介面確保實現類別提供特定的方法實現，而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
上一篇文章提到有些介面不應被繼承，但物件導向的子類別只能繼承父類別的介面，因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制，這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承，更適合使用組合，根本不需要使用繼承疊加特性。
資料類型的定義往往跟怎麼建構模型相
類似於trait/typeclass的特性系統能提供程式「延展性」，它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像，然而特性系統的彈性比較大一點，而且概念上也有一些差別。為了探討討論這些差異，我們必須深入了解繼承機制到底是什麼。
繼承並不是建立子類關係的唯一方法。所謂的