====== 2.3.4.8.4.4 Abstract/Virtual Methods ======
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start| Return to Operation Data]]

===== Overview =====
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:05_abstract | Return to Top]]

An **Abstract Method**, or **Virtual Method**, are methods that are declared but has no underlying implementation (i.e., no body). The primary purpose of these methods is to form a base, template, or guide for subsequent Data Objects derived from this **Data Object**. The derived Data Objects all have the same behavior defined by the Abstract Methods of the base object. The original base **Data Object** is considered as Abstract or Virtual since, without implementation for these methods, the **Data Object** remains a "concept". 

Almost all [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] languages provide for the concept of **Abstract** or **Virtual** methods. In recent years, the concept of **Virtual** or **Abstract** **Data Objects** have lost favor to the use of **Generics** or **Templates** which can be instantiated for a particular type. For example, a double-linked-lst template, or a name-value pair template.

There are benefits of using Abstract **Data Objects**((
Simplilearn,
__What is an Abstract Class in Java and How to Implement It?__,
Accessed: 3 November 2021,
[[https://www.simplilearn.com/tutorials/java-tutorial/abstract-class-in-java]]
)):

| Template           | The abstract **Data Object** enables the best way to execute the process of data abstraction by providing the developers with the option of hiding the code implementation. It also presents the end-user with a template that explains the methods involved. |
| Loose Coupling     | Data abstraction in **Data Object**  enables loose coupling, by reducing the dependencies at an exponential level. See [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system]] |
| Code Reusability   | Using an abstract **Data Object** in the code saves time. Abstract Data Objects avoid the process of writing the same code again.|
| Abstraction        | Data abstraction in **Data Objects** helps systems hide code complications and implementation details from **Derived Classes** (i.e., subclasses) aiding developers of **Base Object** and **Derived Object** to focus their attention on an appropriate level. |

<figure>
{{  :dido:public:ra:1.2_views:3_taxonomic:4_data_tax:screen_shot_2021-11-03_at_6.05.06_pm.png?600  |}}
<caption>Relationship of Abstract Interfaces with realized Data Objects</caption>
</figure>

===== DIDO Specifics =====
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:05_abstract | Return to Top]]

Doug Crescenzi ((
_Solidity: How to know when to use Abstract Contracts vs Interfaces__,
Doug Crescenzi,
13 June 2018,
Accessed 3 November 2021,
[[https://medium.com/upstate-interactive/solidity-how-to-know-when-to-use-abstract-contracts-vs-interfaces-874cab860c56]]
)) does an excellent job in summarizing the use of Abstract [[dido:public:ra:xapend:xapend.a_glossary:s:smart_contract]] and Interfaces.

[[dido:public:ra:xapend:xapend.a_glossary:e:ethereum]] allows for both Interfaces and for Abstract Contracts (i.e., Data Objects). An **Abstract Smart Contract** is any Smart Contract that has at least one method specified that does not have a corresponding body (implementation). This means that the **Abstract Data Object** acts like a **Base Class**, then the **Derived Class** MUST provide an implementation for the abstract method(s). 

<Code solidity>
pragma solidity ^0.4.24;

contract Person 
{ function gender() public returns (bytes32);
}

contract Employee is Person 
{ function gender() public returns (bytes32) 
    { return "female"; }
}
</Code>

<color blue><todo @char>Review </todo></color>

/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
/* To add a discussion page to this page, comment out the line that says 
 ~~DISCUSSION:off~~
*/
~~DISCUSSION:on|Outstanding Issues~~
~~DISCUSSION:off~~