# Smart Contract Design Pattern for Processing Logically Coherent Transaction Types
## 3 The Pattern Design and Implementation
### Concrete Layer
```
publicExchangeEnergyContract(){ //verificationrules rulesList.add(t -> ((Transaction) t).getSourceID()!= ((Transaction) t).getTargetID()); rulesList.add(t -> ((Transaction) t).getQuantity() > 0); rulesList.add(t -> ((Transaction) t).getSourceSurplus() >= ((Transaction) t).getQuantity()); rulesList.add(t -> ((TransactionCross) t).getSourceCommunityID()!= (( TransactionCross) t).getTargetCommunityID()); rulesList.add(t -> ((Transaction) t).getTargetNeed() >= ((Transaction) t).getQuantity()); rulesList.add(t -> ((TransactionGrid) t).getTargetID() == ((TransactionGrid) t ).getEnergySubnetID()); //configurations for (int i = 1; i <= 2 ; i++) configurations.add(new ArrayList<>()); //configures rulesforTransactionIn configurations.get(0).add(rulesList.get(0)); configurations.get(0).add(rulesList.get(1)); configurations.get(0).add(rulesList.get(2)); //configures rulesforTransactionGrid configurations.get(1).add(rulesList.get(0)); configurations.get(1).add(rulesList.get(1)); configurations.get(1).add(rulesList.get(2)); configurations.get(1).add(rulesList.get(5)); //configures rulesforTransactionCross configurations.get(2).add(rulesList.get(3)); configurations.get(2).add(rulesList.get(0)); configurations.get(2).add(rulesList.get(1)); configurations.get(2).add(rulesList.get(2)); configurations.get(2).add(rulesList.get(4));

Figure 5: Classes for transaction types for the _SendEnergy_ use case. In the constructor of the _ExchangeEnergyContract_ class, the list of verification rule objects is created in the form of lambda expressions. It is worth noting that verification rules 4 and 6 are dedicated to processing objects of the _TransactionCross_ and _TransactionGrid_ classes, respectively. The constructor also sets configurations as distinct lists of references to verification rule objects for each transaction type. The _checkSC()_ method, implemented in the smart contract abstract class, operates on the first configuration of verification rules. In a specific smart contract class, this method should be overloaded as many times as there are additional transaction types. In the example considered, two more methods had to be written. One method for the cross-community transaction type and one for the to-grid transaction type. Importantly, if the _checkSC()_ method is called with a transaction type other than declared for the smart contract, it will execute correctly and return a _false_ logical value. The _true_ logical value, which proves the correct verification of the transaction, may be returned only for one of the considered transaction types. The source code of the _checkSC()_ method for handling _TransactionGrid_ transactions was shown in Listing 4. ```
publicbooleancheckSC(TransactionGridtr){ booleancorrect=false; for(Predicate<AbstractTransaction>vR:configurations.get(1)){ correct=vR.test(tr); if(!correct)break; } returncorrect; }
```
On invocation of the _checkSC()_ method, Java verifies the parameter type and calls that appropriate method from those overloaded. The calling of the overloaded _checkSC()_ method is shown in the UML Sequence diagram (Figure 6). The order in which the verification rules appear in the configuration matters, because the _checkSC()_ method evaluates the verification rules in the order they were set in the configuration. Evaluation of the configuration is aborted if a single verification rule is not met. Such a way of evaluation shortens the smart contract checking time. Figure 6: Calling the smart contract verification method. The source code of the _Transaction_ class is presented in Listing 5.