1. Interfaces
An interface defines what a contract must do, but provides zero implementation. It’s a architectural blueprint.
Properties: no state variables, no constructor, and all functions must be external.
Use Case: Interaction. You use interfaces to talk to other contracts (like calling balanceOf on a USDC contract).
2. Abstract Contracts
An abstract contract contains some logic but leaves other parts for the "child" contract to implement.
Properties: Can have state variables, internal functions with logic, and constructors. If at least one function is missing its body or marked virtual, the contract must be declared abstract and can not be deployed.
Use Case: Templates. You use this when you have a "base" design that can be specialized later.
3. Libraries
Libraries are stateless and intended to be reused.
Properties: no state variables, cannot receive Ether, and cannot be destroyed. They are meant to perform operations on the data you pass to them.
Use Case: Utility functions. Think of the SafeERC20 or SafeMath libraries. They provide "helper" logic that many contracts can use.
Comparison Table:
| Feature | Library | Abstract | Interface |
|---|---|---|---|
| Can have state | ❌ | ✅ | ❌ |
| Can have implementation | ✅ | ✅ | ❌ |
| Can be instantiated | ❌ | ❌ | ❌ |
| Can be inherited | ❌ | ✅ | ✅ |
| Must implement all functions | N/A | ❌ (only abstract ones) | ✅ |
| Function visibility | internal/external | Any | external only |
| Used for | Utility functions | Shared implementation | Defining standards |
Top comments (0)