Chapter 5 · Solidity foundations · lesson 13

Inheritance

10 min

You have written the same owner-and-modifier block three times now. Inheritance is how you stop.

contract Store is Ownable { ... }

A child gets the parent's state variables, functions, modifiers and errors, and the parent's constructor runs first.

Store.solComplete

Loading editor…

Store should reuse Ownable rather than redeclaring the owner logic.

Run the code to see what happens.

Nudge

`Store` uses `onlyOwner`, but nothing in `Store` defines it. Where is it defined?

Show me the approach

Solidity inherits with the `is` keyword, and a child gets the parent's state, modifiers and errors.

Show me the code

Change `contract Store {` to `contract Store is Ownable {`.

Explain the solution

`contract Store is Ownable`. The parent constructor runs first, so `owner` is set before Store's own code — which is why the deployer ends up owning it without Store writing a constructor at all.

What you actually inherit

Notice Store never declared owner, never wrote a constructor, and still ends up owned by whoever deployed it. All of that came from Ownable.

Inheritance in Solidity is flattened at compile time. There is no runtime delegation and no separate parent object — the compiler produces a single contract containing everything, deployed at a single address.

That matters for storage. Parent state variables occupy slots before the child's, and getting that order wrong is what breaks upgradeable proxies, a track 7 topic.

override and virtual

A parent function can only be replaced if it opts in:

contract Ownable {
    function transferOwnership(address to) public virtual onlyOwner { ... }
}

contract Store is Ownable {
    function transferOwnership(address to) public override onlyOwner { ... }
}

virtual means "this may be replaced". override means "this replaces something". Solidity requires both, so an accidental override cannot compile.

Predict

Why does Solidity insist on both `virtual` and `override` when other languages need neither?

So you cannot silently replace a parent's function by reusing its nameTo let the compiler optimise the callBecause Solidity supports multiple inheritance

Multiple inheritance, and the order that bites

contract Token is ERC20, Ownable, Pausable { ... }

Solidity linearises parents right to left: the rightmost is the most base, the leftmost the most derived. Get the order wrong and you can end up with a different function than you intended, or a compile error about linearisation.

The convention is to list them from most base-like to most derived, which is what OpenZeppelin does throughout.

Check

`Store is Ownable`. Who runs first at deployment?

Ownable's constructor, then Store'sStore's constructor, then Ownable'sThey are two separate deployments

Worth remembering

`contract Child is Parent` inherits state, functions, modifiers and errors.
Inheritance is flattened at compile time into a single contract at a single address.
Parent constructors run before the child's.
Replacing a function needs `virtual` on the parent and `override` on the child, so accidents cannot compile.
Multiple inheritance linearises right to left — list parents most-base first.