26.09.2013 Views

Transformation of Applicative Specifications into Imperative ...

Transformation of Applicative Specifications into Imperative ...

Transformation of Applicative Specifications into Imperative ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

;<br />

|<br />

|<br />

. . .<br />

9.6 The Visitor Modules<br />

9.6. THE VISITOR MODULES<br />

) ∗<br />

RPAREN<br />

{p = new RecordPattern (<br />

vovn . value_or_variable_name ( ) ,<br />

i n n e r P a t t e r n L i s t ) ; }<br />

UNDERSCORE { p = new WildcardPattern ( ) ; }<br />

The visitors are built using the visitor design pattern. The purpose <strong>of</strong> the<br />

visitor design pattern is to separate a hierarchical structure <strong>of</strong> classes from<br />

tasks which must be performed on the structure itself. When following the<br />

visitor design pattern, tasks that would normally be placed in the functionality<br />

<strong>of</strong> the individual class are put inside one single class, called a visitor.<br />

When using the visitor design pattern an abstract visitor class is created.<br />

This abstract class contains one method, visitClassName, for each class,<br />

ClassName, in the hierarchical structure. To each class in the structure a<br />

method <strong>of</strong>ten called accept or visit is added. This method takes a visitor as<br />

argument and calls the visitClassName method.<br />

In order to fulfill a task a concrete visitor, which can perform the actual<br />

task, is implemented as an implementation <strong>of</strong> the abstract visitor. Each <strong>of</strong><br />

the visit methods in the concrete visitor are implemented such that each <strong>of</strong><br />

them implements a part <strong>of</strong> the whole task.<br />

The advantage <strong>of</strong> the visitor design pattern is that when a new task is<br />

needed, the only thing to do is to make a new concrete visitor. No changes<br />

are needed in the classes <strong>of</strong> the structure. If the functionality <strong>of</strong> a visitor<br />

must be changed, the only class that needs to be changed is the visitor class<br />

itself.<br />

In the transformer program the RSLAstVisitor.rsl is an abstract visitor<br />

and the StringRSLAstVisitor.rsl is a concrete visitor, which can perform<br />

the task <strong>of</strong> turning an RSL AST <strong>into</strong> an RSL ASCII specification. Part <strong>of</strong> a<br />

class diagram showing the use <strong>of</strong> the visitor design pattern in the transformer<br />

program can be found in Figure 9.6 on the following page. Code snippets<br />

<strong>of</strong> StringRSLAstVisitor.java can be found in Example 9.2. The entire<br />

source code <strong>of</strong> the visitor modules can be found in Appendix F.<br />

103

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!