Solidity and object oriented programming (OOP)
By: Tech Geek
Tags: Ethereum, Programming, Solidity, Object Oriented, Blockchain Technology

Contract Composition :

Solidity supports contract composition. Composition refers to combining multiple contracts or data types together to create complex data structures and contracts.

It is a good practice to break down problems into multi-contract solutions and compose them together using contract composition.

Inheritance :

Inheritance is one of the pillars of object orientation and Solidity supports inheritance between smart contracts. Inheritance is the process of defining multiple contracts that are related to each other through parent-child relationships.

The contract that is inherited is called the parent contract and the contract that inherits is called the child contract.

Similarly, the contract has a parent known as the derived class and the parent contract is known as a base contract.

Inheritance is mostly about code-reusability. There is a is-a relationship between base and derived contracts and all public and internal scoped

functions and state variables are available to derived contracts.

In fact, Solidity compiler copies the base contract bytecode into derived contract bytecode. The is keyword is used to inherit the base contract in the derived contract. It is one of the most important concepts that should be mastered by every Solidity developer because of the way contracts are versioned and deployed.

Solidity supports multiple types of inheritance, including multiple inheritance. Solidity copies the base contracts into the derived contract and a single contract is created with inheritance. A single address is generated that is shared between contracts in a parent- child relationship.

Single inheritance :

Single inheritance helps in inheriting the variables, functions, modifiers, and events of base contracts into the derived class.

Single inheritance

Multi-level inheritance:

Multi-level inheritance is very similar to single inheritance; however, instead of just a single

parent-child relationship, there are multiple levels of parent-child relationship.

Multi-level inheritance

This is shown in the following diagram. Contract A is the parent of Contract B and Contract B is the parent of Contract C:

Hierarchical inheritance :

Hierarchical inheritance is again similar to simple inheritance. Here, however, a single contract acts as a base contract for multiple derived contracts.

Hierarchical inheritance

This is shown in the following diagram. Here, Contract A is derived in both Contract B and Contract C:

Multiple inheritance :

Solidity supports multiple inheritance. There can be multiple levels of single inheritance.

However, there can also be multiple contracts that derive from the same base contract.

These derived contracts can be used as base contracts together in further child classes.

When contracts inherit from such child contracts together, there is multiple inheritance, as shown in the following diagram:

Multiple inheritance :

Note : Solidity follows the path of Python and uses C3 Linearization, also known as Method Resolution Order (MRO), to force a specific order in graphs of base contracts. The contracts should follow a specific order while inheriting, starting from the base contract through to the most derived contract.

Encapsulation :

Encapsulation is one of the most important pillars of OOP. Encapsulation refers to the process of hiding or allowing access to state variables directly for changing their state.

It refers to the pattern of declaring variables that cannot be accessed directly by clients and can only be modified using functions. This helps in constraint access to variables but, at the same time, allows enough access to class for taking action on it.

Solidity provides multiple visibility modifiers such as external , public , internal , and private that affects the visibility of state variables within the contract in which they are defined, inheriting child contracts or outside contracts.

Polymorphism :

Polymorphism means having multiple forms. There are the following two types of polymorphism:

1. Function polymorphism

2. Contract polymorphism

Function polymorphism :

Function polymorphism refers to declaring multiple functions within the same contract or inheriting contracts having the same name.

The functions differ in the parameter data types or in the number of parameters. Return types are not taken into consideration for determining valid function signatures for polymorphism. This is also known as method overloading.

pragma solidity ^0.4.19; contract helloFunctionPloymorphism {



function getVariableData(int8 data) public pure returns(int8 output) {

return data;

} function getVariableData(int16 data) public pure returns(int16 output) {

return data;

}

}

Contract polymorphism:

Contract polymorphism refers to using multiple contract instances interchangeably when the contracts are related to each other by way of inheritance. Contract polymorphism helps in invoking derived contract functions using a base contract instance.

pragma solidity ^0.4.19; contract ParentContract {

uint internal simpleInteger; function SetInteger(uint _value) public {

simpleInteger = _value;

} function GetInteger() public view returns (uint) {

return 10;

}

} contract ChildContract is ParentContract {



function GetInteger() public view returns (uint) {

return simpleInteger;

}

}

Abstract contracts :

Abstracts contracts are contracts that have partial function definitions. You cannot create an instance of an abstract contract.

An abstract contract must be inherited by a child contract for utilizing its functions.

Abstract contracts help in defining the structure of a contract and any class inheriting from it must ensure to provide an implementation for them.

If the child contract does not provide the implementation for incomplete functions, even its instance cannot be created.

The function signatures terminate using the semicolon, ; , character.

There is no Solidity-provided keyword to mark a contract as abstract.

A contract becomes an abstract class if it has functions without implementation.

pragma solidity ^0.4.19; contract abstractHelloWorld {

function GetValue() public view returns (uint);

function SetValue(uint _value) public; function AddNumber(uint _value) public returns (uint) {

return 10;

}

} contract HelloWorld is abstractHelloWorld{

uint private simpleInteger; function GetValue() public view returns (uint) {

return simpleInteger;

}



function SetValue(uint _value) public {

simpleInteger = _value;

} function AddNumber(uint _value) public returns (uint ){

return simpleInteger = _value;

}

}

Interfaces :

Interfaces are like abstract contracts, but there are differences. Interfaces cannot contain any definition.

They can only contain function declarations. It means functions in interfaces cannot contain any code.

They are also known as pure abstract contracts. An interface can contain only the signature of functions.

pragma solidity ^0.4.19; contract abstractHelloWorld {

function GetValue() public view returns (uint);

function SetValue(uint _value) public; function AddNumber(uint _value) public returns (uint) {

return 10;

}

} contract HelloWorld is abstractHelloWorld{

uint private simpleInteger; function GetValue() public view returns (uint) {

return simpleInteger;

}



function SetValue(uint _value) public {

simpleInteger = _value;

} function AddNumber(uint _value) public returns (uint ){

return simpleInteger = _value;

}

}

Summary :

In this article I focused primarily on smart contracts, the different ways to create an instance, and all the important object-oriented concepts related to them, including inheritance, polymorphism, abstraction, and encapsulation.

Multiple types of inheritance can be implemented in Solidity. Simple,

multiple, hierarchical, and multi-level inheritance were discussed, along with usage and implementation of abstract contracts and interfaces. It should be noted that using inheritance in Solidity, there is eventually just one contract that is deployed instead of multiple contracts. There is just one address that can be used by any contract with a parent- child hierarchy.