Decorator Pattern in the Eclipse Modelling Framework
In the previous article, I discussed how to create generic classes in the Eclipse Modeling Framework (EMF). In this article, I will discuss how to use that knowledge to implement the decorator pattern in EMF. In the process, we will be pushing our knowledge of generics a little further.
In certain cases it is useful or even necessary to wrap legacy Java classes, especially Java beans, in an EMF model. For instance, you may need to display information provided by a Java remote method invocation (RMI) service. You do not have access to the source code, only the JARs.
I personally rely on EMF to handle the display of objects in EMF. Honestly, who wants to write all that code in the EMF.Edit framework? I would much rather right-click on a GENMODEL file and move on.
I have created an example of wrapping or decorating on set objects with another. In this example, we have a legacy Java interface named Aramaic. We will create an EMF model named Greek that will wrap the classes from Aramaic.
Listing 1 shows the Aramaic interfaces. I have kept this as simple as possible. The class Aleph has an attribute surname. The class Beth inherits from Aleph and adds an attribute nickname.
package com.jeffreyricker.aramaic;
public interface Aleph {
public String getSurname();
}
public interface Beth extends Aleph {
public String getNickname();
}Listing 1
Let us assume that we are handed the JAR of this implementation. We would use the Eclipse plug-in wizard to transform the JAR into an OSGI bundle.
Next, we need to create our EMF model that will wrap or decorate the objects that implement the Aramaic interfaces. I want to keep this as clean as possible. The EMF interface should mirror but have no reference to the legacy interfaces. The result is shown in Listing 2.
/**
* @model
*/
public interface Alpha {
/**
* @model
*/
public String getName();
}
/**
* @model
*/
public interface Beta extends Alpha {
/**
* @model
*/
public String getNickname();
}
Listing 2
The actual wrapping is hidden in the implementation. There is no reference to the Aramaic classes in the Greek interfaces.
We need a basic interface for the decorating. Here is where the generics begin. The Decorator interface shown in Listing 3 is very basic. The generic <D> is the class that will be wrapped by the decorator. The implementation of the interface is shown in Listing 4.
package com.jeffreyricker.greek.util;
public interface Decorator<D> {
D getDecorated();
void setDecorated(D decorated);
}
Listing 3
package com.jeffreyricker.greek.impl;
import org.eclipse.emf.ecore.impl.EObjectImpl;
import com.jeffreyricker.greek.util.Decorator;
public class DecoratorImpl<D> extends EObjectImpl implements Decorator<D>{
private D decorated;
public D getDecorated() {
return decorated;
}
public void setDecorated(D decorated) {
this.decorated = decorated;
}
}
Listing 4
Jeffrey Ricker is an experienced technology development executive with 15 years of leadership in defense and the private sector. He is the principal of Jeffrey Ricker LLC, providing expertise in Eclipse, RCP and OSGi to Fortune 500 and start-up clients. Previously, he was the founder of Distributed Instruments and XML Solutions Corp. Jeffrey is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 3149 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)









