Solidity Patterns

Recap: From Fundamentals to Patterns

In Module 7, you learned Solidity's core building blocks — types, functions, modifiers, events, and error handling. You built a TodoList contract that worked, but had real limitations. Now it's time to level up: from writing code that works to writing code that is production-ready.

Inheritance & Polymorphism

Solidity supports multiple inheritance. Contracts can inherit state variables, functions, modifiers, and events from one or more parent contracts. This is the foundation for code reuse in the Solidity ecosystem.

The is Keyword

contract Child is Parent { ... } — the child contract inherits all public and internal members from Parent. You can chain inheritance: contract C is A, B { ... }.

virtual and override

A parent marks functions as virtual to allow children to replace them. The child uses override to provide a new implementation. Both keywords are required since Solidity 0.6.0 — the compiler enforces explicit intent.

The super Keyword

super.functionName() calls the parent's implementation. Useful when you want to extend behaviour rather than replace it entirely. In a multiple inheritance chain, super follows the C3 linearization order.

Multiple Inheritance & Linearization

When inheriting from multiple contracts, Solidity uses C3 linearization to determine the order of precedence. The order in the is clause matters: contract C is A, B means B overrides A for conflicting functions.

Constructor Arguments

Pass arguments to parent constructors directly: contract Child is Parent(42) { ... } or in the child's constructor: constructor() Parent(42) { ... }. Both are valid; the first is cleaner for constants.

Inheritance Comparison

Code: Inheritance Chain

An Animal → Dog → GuideDog chain demonstrating virtual, override, and super. Each level extends or replaces the parent's speak() function while optionally calling the parent implementation.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Animal {
    function speak() public pure virtual returns (string memory) {
        return "...";
    }
}

contract Dog is Animal {
    function speak() public pure virtual override returns (string memory) {
        return "Woof!";
    }
}

contract GuideDog is Dog {
    function speak() public pure override returns (string memory) {
        // Calls Dog.speak() via super
        return string.concat(super.speak(), " (trained)");
    }
}

Interfaces & Abstract Contracts

Interfaces define what a contract must do without specifying how. Abstract contracts provide partial implementations — some functions are complete, others are left for children to implement.

Interfaces

An interface has strict rules: no state variables, no constructor, all functions must be external, and no function can have an implementation. Interfaces define a contract (in the legal sense) — a promise of what functions exist.

Abstract Contracts

An abstract contract can have some implemented functions and some unimplemented ones (marked virtual without a body). You cannot deploy an abstract contract directly — a child must implement all missing functions.

When to Use Each

Use an interface to define a standard (like ERC-20). Use an abstract contract when you want to share base logic across multiple children (like a base Token contract with common accounting functions).

Comparison

Code: Interface + Abstract Contract

A simplified IERC20 interface (totalSupply, balanceOf, transfer) alongside an abstract contract Token that implements balanceOf and totalSupply but leaves transfer for children to define.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// ── Interface: defines WHAT ──
interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function approve(address spender, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
}

// ── Abstract: partial HOW ──
abstract contract Token is IERC20 {
    mapping(address => uint256) internal _balances;
    uint256 internal _totalSupply;

    function totalSupply() external view override returns (uint256) {
        return _totalSupply;
    }

    function balanceOf(address account) external view override returns (uint256) {
        return _balances[account];
    }

    // transfer(), approve(), allowance(), transferFrom()
    // are NOT implemented — children must do it
}

Access Control Patterns

Module 7's onlyOwner modifier was simple but limited: one address controls everything. Real production contracts need multiple roles with granular permissions.

Code: AccessControl in Action

A contract inheriting AccessControl with two roles (ADMIN_ROLE, MINTER_ROLE). The constructor grants both roles to the deployer. A mint() function restricted to onlyRole(MINTER_ROLE) demonstrates granular access.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MyToken is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    uint256 public totalMinted;

    constructor() {
        // Deployer gets both roles
        _grantRole(ADMIN_ROLE, msg.sender);
        _grantRole(MINTER_ROLE, msg.sender);
    }

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        totalMinted += amount;
        // ... mint logic
    }
}

Libraries & Gas Optimization

Two ways to write more efficient contracts: reuse code with libraries, and minimize storage costs with gas optimization techniques. Together, they make your contracts cheaper to deploy and cheaper to use.

Libraries

The library keyword defines stateless utility functions. Use using X for Y; to attach library functions to a type. Example: using Strings for uint256; lets you write myNumber.toString(). OpenZeppelin provides libraries like Strings, Address, SafeCast, and Math.

Code: Library + Packed Struct

A library MathUtils with a clamp function, attached via using. Plus a packed struct example showing how reordering fields from uint256, uint8, uint256, uint8 (4 slots) to uint256, uint256, uint8, uint8 (3 slots) saves 20,000 gas.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// ── Library: stateless utility ──
library MathUtils {
    function clamp(uint256 value, uint256 min, uint256 max)
        internal pure returns (uint256)
    {
        if (value < min) return min;
        if (value > max) return max;
        return value;
    }
}

contract PackedExample {
    using MathUtils for uint256;

    // BAD: 4 storage slots
    // uint256 id;      // slot 0
    // uint8   category; // slot 1
    // uint256 amount;   // slot 2
    // uint8   priority; // slot 3

    // GOOD: 3 storage slots (packed)
    uint256 public id;        // slot 0
    uint256 public amount;    // slot 1
    uint8   public category;  // slot 2 (packed)
    uint8   public priority;  // slot 2 (packed)

    function setAmount(uint256 _amount) external {
        // clamp via library: min 1, max 10000
        amount = _amount.clamp(1, 10000);
    }
}

Upgradeable Contracts: The Proxy Pattern

Smart contracts are immutable — once deployed, their code can never change. But bugs happen, and requirements evolve. The proxy pattern solves this without breaking immutability.

The Problem

Deployed code can't change. A bug in a contract holding $100M means those funds could be at risk permanently. You can't patch a smart contract like you'd patch a server.

The Solution: Separate Storage from Logic

Users talk to a Proxy contract (which holds storage). The Proxy forwards every call to an Implementation contract (which holds logic). To upgrade, you deploy a new Implementation and point the Proxy to it. Storage is preserved.

delegatecall

The key EVM opcode: delegatecall executes the Implementation's code in the Proxy's storage context. The Implementation reads and writes the Proxy's state variables, not its own. This is what makes the entire pattern possible.

Storage Collision Risk

The Proxy and Implementation must share the same storage layout. If the Implementation expects uint256 balance at slot 0 but the Proxy has address admin at slot 0, you get corrupted data.

Proxy Architecture

Code: Proxy Concept

A simplified proxy illustration (not production-ready). Shows the delegatecall pattern and how the implementation address is stored. For real contracts, always use OpenZeppelin's proxy implementations.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// ── Simplified Proxy (educational only) ──
contract SimpleProxy {
    // Storage slot for implementation address (EIP-1967)
    bytes32 private constant IMPL_SLOT =
        keccak256("eip1967.proxy.implementation");

    constructor(address _impl) {
        assembly {
            sstore(IMPL_SLOT, _impl)
        }
    }

    // Fallback: forward ALL calls to implementation
    fallback() external payable {
        assembly {
            let impl := sload(IMPL_SLOT)
            calldatacopy(0, 0, calldatasize())
            let ok := delegatecall(
                gas(), impl, 0, calldatasize(), 0, 0
            )
            returndatacopy(0, 0, returndatasize())
            if iszero(ok) { revert(0, returndatasize()) }
            return(0, returndatasize())
        }
    }
}

Your Second Real Contract: Multi-Role Vault

This contract combines everything from this module: inheritance (AccessControl), role-based access, events, custom errors, immutable variables, and gas-optimized history via events instead of storage.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

// ── Custom Errors ──
error Unauthorized();
error InsufficientBalance(uint256 requested, uint256 available);

contract Vault is AccessControl {
    // ── Roles ──
    bytes32 public constant DEPOSITOR_ROLE =
        keccak256("DEPOSITOR_ROLE");
    bytes32 public constant WITHDRAWER_ROLE =
        keccak256("WITHDRAWER_ROLE");

    // ── Immutable (0 gas to read) ──
    uint256 public immutable deployedAt;

    // ── Events ──
    event Deposited(address indexed who, uint256 amount);
    event Withdrawn(address indexed who, uint256 amount);

    // ── Constructor ──
    constructor() {
        deployedAt = block.timestamp;
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(DEPOSITOR_ROLE, msg.sender);
        _grantRole(WITHDRAWER_ROLE, msg.sender);
    }

    // ── Deposit (payable, DEPOSITOR only) ──
    function deposit() external payable onlyRole(DEPOSITOR_ROLE) {
        require(msg.value > 0, "No ETH sent");
        emit Deposited(msg.sender, msg.value);
    }

    // ── Withdraw (WITHDRAWER only) ──
    function withdraw(uint256 amount) external onlyRole(WITHDRAWER_ROLE) {
        if (amount > address(this).balance)
            revert InsufficientBalance(amount, address(this).balance);

        payable(msg.sender).transfer(amount);
        emit Withdrawn(msg.sender, amount);
    }

    // ── View (free off-chain) ──
    function getBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

Contract Breakdown

Exercise & Self-Check