Have you wondered, what if a deployed smart contract is outdated? Consider this scenario, in the US, 2016 income tax laws are invalid. So, are the smart contracts we might have deployed for this. Thus the smart contracts are now useless. What happens to the money tax that any of the smart contracts would have collected? Can we change the ownership of these smart contracts to a trustee account, as we deploy smart contracts for representing the new tax laws? These are questions to be carefully addressed not just for the Internal Revenue Service, but for any business or organization that may deploy a blockchain and a DApp smart contract solution. Recall that a smart contract is identified by an address. This is an important concept. It may represent a token, an organization, a person, human or otherwise and the related logic rules and operations. A smart contract has a owner. By default, it is the creator of the smart contract. It has a value or ether balance. Its ownership may change or it may have to be deleted. Given all these complex attribute, how do you manage a smart contract? To delete or kill a smart contract, Solidity provides a function called self-destruct. Understand this call is irreversible as per the default blockchain protocol. Once killed, the smart contract cannot be revived or accessed. It is like holding an expired spaceship into the abyss of space. Another the good programming practice is to make sure only the owner or the owners of the smart contract or an authorized person has permission to self-destruct a contract. Assume, a time duration is also specified for the contract. Modifiers are used to enforce the destructors address and the time duration for this smart contract. Here is the code. What happens when a kill function is executed. The smart contract code is removed from the state of the blockchain, if the conditions specified by the modifier are satisfied. In our case, the conditions are that, the function is called by the designated address and the time specified has elapsed. The remaining ethers stored in the address of this smart contract is transferred to the address specified in the parameter of the self-destruct call. The smart contract itself is inaccessible by its current address. The next concept is equally important for smart contract design. Recall that smart contract may represent an asset or a business. During the lifetime of an asset, ownership may change. It may change due to the sale of an asset, donation of an asset or by bequeathment. These are just a few. There are many more scenarios for ownership transfer. This function can implement a transfer of ownership, but make sure you qualify the transfer with a modifier or modifiers so appropriate rules are enforced from managing ownership and lifetime. We are moving into managing relationships among smart contracts. So, far we've been creating single smart contract. It is possible a complex application could be composed of many smart contracts, one instantiating the other or inheriting others. It is also possible that the symbols or namespace for an organization is defined in a common smart contract that needs to be applied. Import command can be used to include files in your smart contract. At the time of compilation, associations are made between the important files and the current smart contract and the byte code is generated based on this association. This leads us to the programming practice three. Composability, specialization, and generalization are important tenets from object orientation, that can help in designing smart contract solutions for complex problems. This also promotes re-usability of code and standards across organization and participants, as you will see in a later module. We'll explore inheritance next and its importance in smart contract-based applications. For example, federal laws referred to here as Fedlaws, can be a legal framework that can very well represent an interface smart contract, letting the state and the field offices implement them, as they see fit. In this case, StateLaws and FieldLaws are also smart contracts and they are associated using the import statements. This is inheritance at work. As a subtopic of relationship among smart contract, it is possible to create libraries and import existing libraries into your Solidity smart contract code. Libraries are special smart contract with no ether balance, no payable functions and no state to be stored in the block chain. A fine example is a SafeMath.sol by Zeppelin, that can be included in your smart contract for any math computation. Import SafeMath.sol. Many libraries are yet to be created. You can be sure, many domain specific libraries will emerge. Here is an opportunity. You too can be a creator of a useful library for your application domain. Summarizing, we explored three important concepts in this lesson, memory versus storage attribute for data in a smart contract, managing lifetime and ownership of smart contracts and inheritance. Lifetime and ownership is something unique to smart contract, and some DApp developers may tend to downplay the importance of this. You should not. You will explore many applications of inheritance concept in the next lessons and also in the next module.
