【開發智能合約 - Solidity系列】實作篇Ep.10 - 標準化的介面(Interfaces)

 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」歡迎自行取用。

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

----------------------------------------------------------------------------------

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

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

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