Solidity: How to know when to use Abstract Contracts vs Interfaces

Doug Crescenzi
Jun 13, 2018 · 3 min read

Extensibility is key when it comes to building larger, more complex distributed applications (dapps). Solidity offers two ways to facilitate this in your dapps: abstract contracts and interfaces.

What is an abstract contract?

Contracts in Solidity are akin to classes in object-oriented languages. They include state variables that contain persistent data as well as functions that can manipulate the data in the state variables. Contracts are identified as abstract contracts when at least one of their functions lacks an implementation. As a result, they cannot be compiled. They can however be used as base contracts from which other contracts can inherit from.

Here’s an example:

pragma solidity ^0.4.24;

contract Person {
function gender() public returns (bytes32);
}

contract Employee is Person {
function gender() public returns (bytes32) { return "female"; }
}

Along with improved extensibility, abstract contracts provide better self-documentation, instill patterns (like the Template method), and eliminate code duplication.

What is an interface?

Interfaces are similar to abstract contracts, but they are limited to what the contract’s ABI can represent. In other words, you could convert an ABI into an interface, or vice versa, and no information would be lost. According to the Solidity docs they have a few additional restrictions. For instance:

  1. Interfaces cannot have any functions implemented

Interfaces are expressed using the interface keyword. Here’s an example:

pragma solidity ^0.4.24;

interface token {
function totalSupply() public view returns (uint256);function balanceOf(address who) public view returns (uint256);function transfer(address to, uint256 value) public returns (bool);}

When should you use an abstract contract instead of an interface?

Abstract contracts are particularly useful when you want to instill patterns — like the template method — into the dapp you’re building. They give you the ability to implement most of a contract yet you can still include abstract functions in it in order to define and self-document the skeleton of your dapp. Doing so facilitates extensibility, removes code duplication, and reduces overhead when you have multiple contracts that need to communicate with one another.

Additionally, abstract contracts help with debugging. Your compiler will report warnings and errors if it uncovers inconsistencies in your dapp’s patterns.

When should you use an interface instead of an abstract contract?

Interfaces are most useful when it comes to designing larger scale dapps prior to their comprehensive implementations. They make it easy to facilitate extensibility in your dapps without introducing added complexity. Many of their built in constraints (listed above) are what can ultimately be used to inform your decision as to whether or not to use an interface instead of an abstract contract.

Takeaways

  • When you’re building large, complex dapps, extensibility is key.

Upstate Interactive

We're a women-owned business that helps B2B organizations turn great ideas into software.

Doug Crescenzi

Written by

We build smart contracts and distributed applications @ Upstate Interactive http://upstateinteractive.io - Founder @ Hack Upstate http://hackupstate.com

Upstate Interactive

We're a women-owned business that helps B2B organizations turn great ideas into software.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade