# Reconfigurable Smart Contracts for Renewable Energy Exchange with Re-Use of Verification Rules
## 6 The Pattern Implementation  
The implementation of the pattern was done in the Java language. The author used the IntelliJ IDEA with the Open Java Development Kit applied in the 18 General-Availability Release version [45]. The source code was placed in the _pl.gdynia.amw.scdp_ package and further split into two packages:  
* Contracts--the package consists of the _SmartContract_ abstract class and one the _ExchangeEnergy/Contract_ class for concrete smart contract;
* exchangeEnergy--contains concrete verification rules classes, i.e.: _TechnicalVR1_, _TechnicalVR2_, _BusinessVR1_, _BusinessVR2_, and _ExpandingVR1_;
- crossCommunity--contains concrete extended verification rules classes for cross community energy exchange, i.e., _TechnicalVR1 Extended_; _ExpandingVR1 Extended_. In the _VerificationRule_ interface, there is declared one abstract method, _runRule()_ (Listing 1).  
```
packagepl.gdynia.amw.scdp.rules; importpl.gdynia.amw.scdp.Transaction; publicinterfaceVerificationRule{ booleanrunRule(Transactiontr); }
```  
Figure 5: The structure of the pattern in the UML class diagram.  
The _SmartContract_ abstract class declares an instance variable _rulesList_ with a list of verification rules classes. The variable declaration uses the _VerificationRule_ interface as a reference data type. Such a declaration allows for the usage of the polymorphism mechanism and storing in reference variable address of the list of concrete verification rules classes. The class also declares the _checkSC()_ abstract method devoted for inspecting the list of verification rules. The class declaration includes the _sealed_ keyword. Classes that can extend the _sealed_ class directly have to be listed after the _permits_ reserved keyword. That allows for control over what concrete classes of smart contracts can inherit from the smart contract abstract class. In consequence, only explicitly specified classes are allowed to be implemented.  
In the presented example, the inheritance ability is granted only to two classes _ExchangeEnergyContract_ and _BuyEnergyFromGrid_ (Listing 2).  
```
packagepl.gdynia.amw.scdp.contracts; importpl.gdynia.amw.scdp.Transaction; importpl.gdynia.amw.scdp.rules.VerificationRule; importjava.util.List; publicabstractsealedclassSmartContractpermitsExchangeEnergyContract, BuyEnergyFromGrid{//listofverificationrules protectedList<VerificationRule>rulesList;//verificationofthesmartcontract publicabstractbooleancheckSC(Transactiontr); }
```  
Listing 2: The source code of the SmartContract class.  
The pattern requires the implementation of each specific verification rule. It comes down to implementing the _runRule()_ method defined in the interface. Such a declaration allows the use of the polymorphism mechanism. The method invocation on the interface variable means indirectly executing its overrident implementation in a concrete verification rule class. The method should be implemented as a _pure_ one. A Java method can be regarded as _pure_ granting that fulfills two conditions. Firstly, solely the input parameters of that method may have an impact on the return value. Secondly, the execution of the method must have no side effects. A _pure_ method cannot change the value of any outside variable. Moreover, the output should always be the same for the specific input. The pattern assumes that technical verification rules are checked before business ones.