When we use OpenZeppelin libraries, depending on the complexity of the project we're working on, we could need to implement multiple inheritances. As we know, in Solidity, the order of inheritance is important, going from most based-like to most derived.
OpenZeppelin is constantly including in their library more extensions, and I would like to what would be the best practice to use them. For this, I see two paths:
- A constantly increasing list of extensions in the inheritance of our smart contracts.
- A recommendation of only using inheritance for use cases that fits in a few extensions (let's say two or three max).
I want to know what the community thinks about which path is best and why in the context of more complex use cases; let's say one smart contract implementing Enumerable, Pausable, URIStorage, and Royalty extensions.
Personally I don't see a huge issue with having a big list of inherited contracts. The issues only present when those contracts conflict and override one another's functions. I think what you need to watch out for is a big list of override functions. However, some OpenZeppelin contracts like the Governor contracts make use of this as a means to modularity. We try to make it so that the necessary overrides aren't too many, but sometimes there is no other way. In these cases, just make sure to pay attention to the documentation and use the contracts according to our recommendations.
A common mistake is not using super. If you need to write an override, it should always look like this:
function foo(x, y, z) override(A, B) returns (...) {
return super.foo(x, y, z); // <- use super.foo here, not A.foo and not B.foo
}
(The return is usually not necessary though.)
We have some guidelines about overrides and inheritance in our documentation: Extending Contracts.