Nice solution @Meriem
Can we also see what modifications youâve made to the start of your Bank.sol file, and Bank contract header, for the inheritance?
You can also develop the inheritance structure one stage further, in order to keep the contract ownership and contract destruction functionality separate â each within its own contract e.g. Ownable and Destroyable. You would then need to decide how to change your exisiting code for this inheritance structure, because you would now have three contracts instead of just two.
Iâm not sure I fully understand your question. Are you asking why we need the âownableâ functionality (as follows) at all here?
If we donât restrict close() to the contract owner (the deployer of the derived contract, Bank) then anybody could be msg.sender, call close() and destroy Bank by triggering selfdestruct. Furthermore, when selfdestruct() is triggered, the ether balance remaining in Bank will be transferred to whichever address argument it is called with. It, obviously, makes sense that we would want to restrict this to an address such as the contract ownerâs.
So, by making close()âonlyOwner
,âthe msg.sender can only be the owner
address, meaning that only the owner can destroy their own contract. In Solidity v0.7.5, msg.sender
is payable by default, so instead of:
we can have the more concise:
selfdestruct(msg.sender);
We could also call selfdestruct() with owner
, like thisâŚ
selfdestruct(payable(owner));
or, by storing the owner address as a payable address in the state variable, from the outsetâŚ
address payable owner;
...
function close() public onlyOwner {
selfdestruct(owner);
}
Let us know if anything is unclear, or if you have any questions