What is the use of a interface or function without implementation?

Question

Take, for example, this code. The interface contains function without implementation, so how it's useful.

pragma solidity ^0.5.0;

interface Calculator {
   function getResult() external view returns(uint);
}
contract Test is Calculator {
   constructor() public {}
   function getResult() external view returns(uint){
      uint a = 1; 
      uint b = 2;
      uint result = a + b;
      return result;
   }
}

How does this code working is different from the first one? What are the benefits of using an interface or function without implementation?

pragma solidity ^0.5.0;

contract Test {
   constructor() public {}
   function getResult() external view returns(uint){
      uint a = 1; 
      uint b = 2;
      uint result = a + b;
      return result;
   }
}

Answer 1

• To economize on bytecode size in calling contracts.
• To establish standards and ensure compliance.
• To detect developer errors and oversights.

Economize

Consider contract Client that will interact with Test. One can create an instance of Test in the client, like this:

contract Client {

  Test t;

  constructor(address test) public {
    t = Test(test);
  }
}

This will work, but the problem is Client will have bytecode size of Test size plus Client size owing to the fact that the compiler will roll up the complete Test implementation into Client. Client doesn't need all of that code. It only needs the interface for the functions it will call.

It can achieve the same result with a smaller bytecode if uses the interface contract instead - Calculator in your example, or naming like ITest which is a de facto naming standard.

contract Client {

  Calculator c;

  constructor(address calculator) public {
    c = Calculator(calculator);
  }
}

As an aside, you can cast the input (will still be an address) as the contract Type:

constructor(Calculator calculator) public {
  c = calculator;
}

Sweet.

Standards

Many standards are defined as function interfaces and specifications of precise behaviour. For example, ERC20 is an interface but no particular implementation as long as the functions work a certain way - that can be confirmed with a test suite. It is common to see something like:

contract MyToken is IERC20 {
  ...

where IERC20 is the defined interface for an ERC20 contract.

If MyToken is deployable, then that establishes that there is an implementation (not undefined) for each function required for the IERC20 interface. This is related to ...

Developer Errors

Inconsistency can creep into intricate systems in the development stage. It can also be cognitively heavy for reviewers to detect inconsistency. Interfaces can function as a sort of error-detection.

Suppose someone decides that getResult() needs an argument, e.g. getResult(address user) .... That's a non-trivial design change that will affect a lot of things. Since contract Test is Calculator { Test will not deploy unless the interface is updated.

Why/How?

Function signatures are the first 4 bytes of a hash of the function name and arguments, so getResult() and getResult(uint) are completely different functions at the bytecode level. In practice, that means Test will compile, but it won't deploy because it will not define one of the mandatory functions defined in the inherited interface.

That is exactly what we want because either a) the interface has been redefined, meaning all clients need to adjust, or b) the implementation is incorrect, meaning adding that argument is unacceptable or c) there is a missing implementation and the one provided is in addition to the mandatory functions, but not a replacement (both are needed).

For style and consistency, it can be a good habit to define interfaces for implementations on a 1:1 basis.

Hope it helps.