Return to Operation Data

Return to Top

An Accessor Method is an Operation defined by Object-Oriented Programming (OOP) providing access to Field Data. There are generally two Accessor Methods defined: get and set. In some Object-Oriented (OO) paradigms, the Accessor methods are further defined as:

• Accessor Methods provide Read-Only access to the Field Data. Accessor Methods provide a way to obtain the state of an object's Field Data from outside the Object.
• Mutator Methods provide Write-Only access to the Field Data. A Mutator not only does simple checking of the data being set such as type and bound checking; it can also check the semantics of the Field Data to ensure they are valid and consistent. For example, using a Mutex Method to deduct a payment, might also set the date of the payment at the same time even though they are separate Fields within the Object.

Note: There may or may not be any MUTual EXclusion (mutex) or Resource Lock associated with the Field Data.

Note: Often both the Accessor and the Mutator are simply referred to as the Accessors.

Note: Both the Accessor and the Mutator are designated as public, but they can also be declares as private or protected. Those that are designated Private can only be used from within the Object. Public designations allow for the methods to be used from inside and outside the Object. Protected allows the internal Object Methods to access the methods, but also allows any Objects derived from the Object to access the methods.

Some benefits of using a Mutator Methods include:

• The prevention of data corruption by directly accessing the private Field Data of an Object
• The flexibility in modifying the internal representation of the Data Fields of an Object without breaking the Interface and consequently code that depends on the Interface.
• The ability to include additional processing logic such as validation of a value set, triggering of events, etc. during mutation of the Field Data or adding Data Logging of acccesses.
• The ability to add MUTual EXclusion (mutex) or Resource Lock for synchronizing multithreading or multiprocessor scenarios.
• The ability to define Accessor and Mutator methods in derived Data Objects from the base Data Object.

The following discussion is uses c++, however, it is very similar to Java and a “verbose C#” form. C# has some shorthand ways of coding accessor and mutator operations (see the next section).

In C++, the accessor methods are usually implemented as getter operations and the mutator functions are usually implemented as setter operation. The use of the prefix get and set at the beginning of a function name is merely a programming convention, and there is nothing within the C++ language to enforce the convention, however, following the naming convention makes it easier for others to read and use the code.

#include <iostream>
using namespace std;

class Account
{ // Private attributes
  private:
    int balance;

  // Public Accessor and Mutator operations
  public:
    // setBalance sets the balance in the account
    void setBalance
      ( int _newBalance ) 
    { balance = _newBalance;
    } // End setBalance
    // getBalance returns the current balance in the account
    int getBalance() {
      return balance;
    } // End getBalance
}; // End Account class

// main used as a unit tester of the Account class
int main() 
{ Account account;
  account.setBalance ( 50000 );
  cout << myObj.getBalance();
  return 0;
} // End Main tester

C# has a shorthand way of specifying that the Accessor and Mutator methods, which reduces the chance of errors in the code since it is generated.

 
using System;

class Account
{ public int balance { get; private set; }
} // End Account Class

Return to Top

The following is an Ethereum Solidity example of a smart_contracts that uses Accessor and Mutator methods (i.e., Getters and Setters). Note: In this examole, there are no method (ie, function ) attributes which designate them as Getters or Setters other than the name convention. However, it is possible to use the View or Pure function attribution to help the compiler enforce the roles of each function type.

pragma solidity ^0.6.0;
    
// A simple smart contract
contract MessageContract 
{
    string message = "Hello World";
    
    function getMessage() public constant 
      returns(string) 
    { return message;
    } // End getMessage
    
    function setMessage(string newMessage) public 
    { message = newMessage;
    } // End setMessage

} // End MessageContract

Ethereum's Solidity can attribute Methods as View.

A method can be declared as view. The following statements if present in the method are considered modifying the state and the compiler throws warning in such cases.

• Modifying state variables
• Emitting events
• Creating other contracts
• Using selfdestruct
• Sending via calls
• Calling any method which is not marked view or pure
• Using low-level calls
• Using inline assembly containing certain opcodes

Getter Method (i.e., Accessor Methods) are by default view methods.

• Note: See: https://www.tutorialspoint.com/solidity/solidity_view_functions.htm

Ethereum's Solidity can attribute Methods as Pure.

Pure methods ensure that they not read or modify the state. A method can be declared as pure. The following statements if present in the method are considered reading the state and compiler will throw warning in such cases.

• Reading state variables.
• Accessing address(this).balance or <address>.balance.
• Accessing any of the special variable of block, tx, msg (msg.sig and msg.data can be read).
• Calling any method not marked pure.
• Using inline assembly that contains certain opcodes.

Pure methods can use the revert() and require() functions to revert potential state changes if an error occurs.

• Note: See: https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm