EJB Inheritance, Part 1
The Object-Oriented Way
Figure 1 shows how the system should be designed. There are three objects here, just
like real life: Base (Regular), Gold, and Platinum customers. They are CMP
entity beans.
Figure 1. Object-oriented approach
Note that there are really three sets of objects to manipulate: local interfaces,
bean classes, and local home interfaces. We see here the bean classes. The
same design is found in the local interfaces, but not in the local home
interfaces. We'll see why later.
Overview of the Steps
The following method enables using inheritance with CMP entity beans, straightforwardly
and reliably. The steps are summarized here, and they will be explained
afterwards.
-
Create a base bean class implementing
EntityBean. Write bean subclasses
extending base bean class.
-
Create a base local interface, extending
EJBLocalObject. Create sub-interfaces
extending base local interface.
-
Write a home interface for base class, extending
EJBLocalHome. Write home
interfaces for subclass, extending EJBLocalHome as usual. Don't extend
home interface of base class.
-
In each subclass'
create or postCreate method, call corresponding base
class's create or postCreate method.
-
For each finder of base class, write a corresponding home method that will
invoke finder in all subclasses. For each
ejbSelect of the base class,
write a regular method that will invoke ejbSelect in all subclasses.
- Optional: Copy home method signatures to subclasses' home interfaces. Override
home methods as required.
-
Set up vendor-specific table mapping.
Let's now explore each step more thoroughly.
1. Bean Classes
Write the base bean class BaseCustomerBean. This abstract class implements
EntityBean. Then write GoldCustomerBean and
PlatinumCustomerBean. The code is provided below for BaseCustomerBean and PlatinumCustomerBean:
Example 2. BaseCustomerBean
//Removed for readability: package, imports.
public abstract class BaseCustomerBean implements EntityBean {
// Removed for readability: constructor, entity
// context, activate, passivate, load, store,
// create, postCreate, remove.
public abstract String getCustomerID();
public abstract void setCustomerID(String newCustomerID);
public abstract String getName();
public abstract void setName(String newName);
public abstract int getPoints();
public abstract void setPoints(int number);
public int addPoints(int purchaseAmount) {
int pts = 0;
pts = purchaseAmount/getPointFactor();
setPoints(getPoints() + pts);
return pts;
}
public int redeemPoints(int zone) {
int pts = getZoneThreshold(zone);
if(getPoints() < pts) return 0;
setPoints(getPoints()-pts);
return pts;
}
protected int getPointFactor() {
return 20;
}
protected int getZoneThreshold(int zone) {
switch(zone) {
case 1: return 1500;
case 2: return 3500;
case 3: return 10500;
case 4: return 25000;
default: return Integer.MAX_VALUE;
}
}
}
Example 3. PlatinumCustomerBean
//Removed for readability: package, imports.
public abstract class PlatinumCustomerBean extends basecustomer.BaseCustomerBean
{
// Removed for readability: constructor, entity
// context, activate, passivate, load, store,
// create, postCreate, remove.
public abstract String getCharity();
public abstract void setCharity(String charity);
protected int getPointFactor() {
return 15;
}
protected int getZoneThreshold(int zone) {
switch(zone) {
case 1: return 1200;
case 2: return 2850;
case 3: return 9500;
case 4: return 20000;
default: return Integer.MAX_VALUE;
}
}
}
As expected, the code for PlatinumCustomerBean is much shorter than
for BaseCustomerBean. Can you see the reuse going on? Note how almost all
of the base class fields and business logic are kept in the subclass. Note
also how "shared" business logic was put in the base class, and class-specific
business logic was put in separate methods, overridden in the subclasses.
Other techniques exist to provide inheritance-like behavior, like aggregation
(the Strategy pattern). But these don't rid us of the dreaded if() else if()
else if() block.