Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Using Marker Interfaces to Represent Design Pattern Metadata in Program Code

IP.com Disclosure Number: IPCOM000109214D
Original Publication Date: 2005-Mar-23
Included in the Prior Art Database: 2005-Mar-23
Document File: 3 page(s) / 33K

Publishing Venue

IBM

Abstract

This article presents the use of the "marker interface" idiom to explicitly mark design pattern participation in program code. Design intention identification at the program code level enhances program understandability.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 3

Using Marker Interfaces to Represent Design Pattern Metadata in Program Code

Tracking design pattern usage (instances of patterns or pattern occurrence) in a program (such as a Java program) usually requires a persistent binding between a pattern role (or pattern parameter) and a pattern participant (pattern argument). When a developer is viewing and reading the resultant program code it is sometimes unknown or totally unobvious to the reader that a pattern occurrence exists. One problem with storing binding information outside of the program code is that the readers of the code are required to refer back to the model that corresponds to the code (to determine if a pattern occurrence) or just "know" that the pattern occurrences exist.

A promise of design patterns is that they enable more productive and efficient communication of designs (and code) by defining a common extensible vocabulary that can be exchanged between developers of designs and code. If the design pattern usage is not local to the code then it might dampen the potential design/code understandability offered by using design patterns in the first place. Other solutions might involve storing pattern occurrence metadata in program code comments but this solution uses a more explicit approach that does not use program code comments.

A solution that complements the storing of binding outside of the program code involves using the "marker interface" idiom to tag classes that play the specific roles in the pattern.

Here is an example of the "marker interface" idiom as used commonly in the Java language.

public interface Cloneable {
}

public class MyClass implements Cloneable {
}

...
{

MyClass myObject = new MyClass();

if (myObject instanceof Cloneable) {

doSomething();

}
}
...

In this example, a Java interface named "Cloneable" is defined without specifying any interface methods. A class named "MyClass" implements the marker interface named "Cloneable". The implementing class is not required to implement any methods since none are defined on the implemented interface. The "marker interface" idiom enables a class to indicate it implements the semantics associated with a specific "marker interface". These semantics transcend any semantics that are expressible via interface

1

Page 2 of 3

methods. At run time in Java (or other languages that have interface and run time introspection) it is possible to test if a given class instance implements or is associated with these semantics (as specified by a particular "marker interface" that the class implements). This example shown above is a real-world example that is currently implemented in the Java JDK and allows a class to specify it fully implements the semantics associated with cloneable. The primary reason for using "marker interfaces" is so an instance can be tested by some other code at run time (via instanceof in Java) to determine if they support the "marker interface" semantics. The use of the marked class instance may vary b...