Return to Operation Data

Return to Top

Pure methods are limited to are often referred to as Pure Functions. Pure Functions are a cornerstone in Functional Programming and are designed to produce no Side Effects. Pure Functions are characterized as follows¹⁾:

• Are dependent only on

  • Declared input parameters
  • Algorithm to implemented
  • Values within the scope of the function, therefore, it can not

    • Depend on accessing any values defined outside the function scope (i.e., another field in the same class, or global variables)
    • Modify mutable values outside the function scope (i.e., other fields in the same class, or global variables)
    • Use external input or output (I/O). It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc.
• Do not modify input parameters

Figure 1 provides a grapic represeting a Pure Function. Basically, the Pure FUnction is an isolated piece of logic that given the same input always produces the same output. It's isolation means it has no unintended sideeffects outside of itself and only the inputs determine the processing. Another way to think of a Pure Function is at their center there is a Deterministic Algorithm (Also see Black Box Testing).

Figure 1: Pure functions

In some languages (i.e., C, C++, Rust, PHP, JavaScript/ECMAScript), it is possible to have methods (i.e., procedures or functions) existing outside the class container. Java and C# requires operations to exist within a class container, and therefore does not support General Methods. C++ does not recommend having General Methods outside of a class, but because C++ is more or less an extension of C, it does support them.

Often, the architecture and design of Functional Programs depends on the identification, design and creation of pluggable, reusable functions. Many of the frameworks used in modern applications reaching across many tiers rely heavily on stateless, client-server Representational State Transfer (REST) models and Command Line Interfaces (CLIs) .

Figure 2 graphically represents pure functions used in a Functional Program.

• The pure functions used in the Functional Program are identified (See items A, B, and C)
• The functions are from a reuse repository (i.e., library), or they can be created especially for the new Functional Program
• The Functional Program is responsible for the lifecycle of each data element (i.e., State Variables)
• The order of the functions is established in the Functional Program
• The association is made of the functions with appropriate the State Variables (which are Input Data and which are Output Data)
• The Functional Program is executed:

  1. The Functional Program is started
  2. Calls are made to the functions in the desired order (i.e., steps 2-4) and the State Variable values are passed into or out of the functions
  3. The Functional Program is terminated

Figure 2: The use of pure Functions in a Functional Program

Return to Top

Ethereum's Solidity is an Object-Oriented Programming (OOP) supporting four closely related object container types (Java and C++ have just one class):

pragma solidity ^0.8.7;
// SPDX-License-Identifier: MIT

interface IERC20 {
    function totalSupply()
      external 
      view 
      returns (uint256);
    function balanceOf
      ( address account 
      ) 
      external 
      view 
      returns (uint256);
    function transfer
      ( address recipient, 
        uint256 amount
      ) 
      external 
      returns (bool);
    function allowance
      ( address owner, 
        address spender
      ) 
      external 
      view 
      returns (uint256);
    function approve
      ( address spender, 
        uint256 amount
      ) 
      external 
      returns (bool);
    function transferFrom
      ( address sender, 
        address recipient,
        uint256 amount
      ) 
      external 
      returns (bool);
    event Transfer
      ( address indexed from, 
        address indexed to, 
        uint256 value
      );
    event Approval
      ( address indexed owner, 
        address indexed spender, 
        uint256 value
     );
} // End  IERC20 interface