[#8946] - Use creation pattern for instance variables on classes intended for reuse.

Category:
Enhancement request
Priority:
Low
Status:
New
Project: Severity:
Major
Resolution:
Open
Component: Reproducibility:
Always
Assigned to:

The class SimpleReportContext shows an example of a class that *could* be reusable, but for a single line of code in the constructor:

this.parameters = new HashMap();

This precludes the possibility of using a different type of map (e.g., a LinkedHashMap that preserves insertion order).

The creation pattern is simple, thread-safe, and follows the Open-Closed principle. Consider the following re-write:

public SimpleReportContext()
{
this.id = System.currentTimeMillis()
+ "_" + System.identityHashCode(this)
+ "_" + RND.nextInt();
}

public Object getParameterValue(String parameterName)
{
return getParameters().get(parameterName);
}

public void setParameterValue(String parameterName, Object value)
{
getParameters().put(parameterName, value);
}

public boolean containsParameter(String parameterName)
{
return getParameters().containsKey(parameterName);
}

private synchronized Map<String, Object> getParameters() {
if( this.parameters == null ) {
this.parameters = createParameterMap();
}

return this.parameters;
}

protected Map<String, Object> createParameterMap() {
return new HashMap<>();
}

At this point, the class can be re-used to ensure parameters maintain their insertion-order:

public XmlReportContext extends SimpleReportContext {
protected Map<String, Object> createParameterMap() {
return new LinkedHashMap<>();
}
}

As it is, SimpleReportContext cannot be re-used. We re-implemented the ReportContext interface and duplicated the entire code for SimpleReportContext -- all for the want of a single "createParameterMap()" method. A bit wasteful. :-)

The creation pattern allows for sub-classes to change behaviour, so long as the new behaviour conforms to the Liskov Substitution Principle.

v6.3
thangalin's picture
1323
Joined: Apr 21 2008 - 4:34am
Last seen: 2 years 5 months ago
Feedback
randomness