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.

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.4.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