4. Software Engineering & Design 37
4.4. Patterns, Java & Extensibility
4.4.3. Extensibility of the Calculator
The two Calculator designs and implementations of the preceding section are extended in all three dimensions.
Vertical extension: Negation
As exemplary vertical extensionNegationshall be available to the calculator as subtype of Expression, see Fig. 4.2. The method calculateof theCalculatorimplementation shall now calculate the result of−(17+4).
Listing 4.5 shows a possible approach for the simple design. The code of thecalculate() Simple Design
method is copied from the simple calculator (see Listing 4.3) and a new line is added that negates the Addition. The class Negation is added as implementation of the -ExpressionJava-interface.
public class SimpleNegationCalculator extends SimpleCalculator { public int calculate( ) {
int add = super.calculate( ) ; Expression c = new Constant(add) ; Negation neg = new Negation(c) ; return neg.eval( ) ;
} }
Listing 4.5: Simple calculator with vertical extension for Negation
In contrast, Listing 4.6 shows the extension for the advanced design. Delegation is Advanced Design
used for everything concerning the calculation of 17+4. The constructor expects a Calculator as parameter. The instance passed is used as delegate. The Negation-ExpressionFactoryinstance is created using theCalculator’s factory as delegate for all operations already available while the methodcreateNegation(Expression e)is added to the factory. In thesetFactory(..)method theNegationExpressionFactoryinstance is passed as factory object to the delegate. The methodcalculate()makes use of the del-egate Calculatorto calculate 17+4. Then it creates aNegation from the result and returns its evaluation.
public class NegationCalculator { private ExpressionFactory factory; private ExtensibleCalculator delegate;
public NegationCalulator(ExtensibleCalculator delegate) { this.delegate = delegate;
this.factory = new NegationExpressionFactoryImpl(delegate. getFactory( ) ) ;
}
public int calculate( ) {
int add = this.delegate.calculate( ) ;
Expression c = this.factory.createConstant(add) ; Expression neg = this.factory.createNegation(c) ; return neg.eval( ) ;
}
public void setFactory(NegationExpressionFactory factory) { this.factory = factory;
this.delegate.setFactory(factory) ; }
}
Listing 4.6: Advanced negation calculator
The native language concepts of Java comprise inheritance. Implementation of vertical
Findings
extensions is relatively easy. Thus, at this point, the simple implementation is more intuitive. The advanced design pays off when other extensions shall be combined with a vertical extension.
Behavioral extension: Debug
As showcase for a behavioral extension, a debug functionality shall be added to the cal-culator in addition to the negation extension. All implementations ofExpressionshall call a print function before evaluating itself. The print function sends the expression to a stream before it is evaluated, e.g.,DEBUG : −(17+4).
If the simple design is extended, one needs to implement calculate() again from
Simple Design
scratch. However, to wrap a few lines around the code of the originalSimpleCalculator as in the vertical extension is no longer sufficient. The behavior of the objects created withincalculate()must be extended. Listing 4.7 shows a potential reimplementation.
Internally, the debug classes could make use of inheritance. E.g., DebugConstant ex-tends the Constant implementation from the SimpleCalculator. Listing 4.8 sketches such an implementation. This ensures that the same code is used for evaluation and only the functionality for debugging needs to be written from scratch. In terms of overall extensibility, this is, however, not helpful.
public class SimpleNegationDebugCalculator { public int calculate( ) {
Expression a = new DebugConstant( 1 7 ) ; Expression b = new DebugConstant( 4 ) ;
Expression add = new DebugAddition(a, b) ; Expression neg = new DebugNegation(add) ; return neg.eval( ) ;
} }
Listing 4.7: Simple calculator with debug extension public DebugConstant extends Constant {
public DebugConstant(int c) { super(c) ;
}
public int eval( ) {
this.printToDebugStream(super.getValue( ) ) ; return super.eval( ) ;
} }
Listing 4.8: Implementation of DebugConstant for the simple calculator
With the advanced design the debugging functionality can be added to the code for the Advanced Design Calculatoror theNegationCalculator. The code is used without any modifications.
There is no need to copy existing code. A factory, that creates instances with additional debug functionality, has to be set as shown in Listing 4.9.
public static void main(String[ ] args) {
NegationCalculator nc = new NegationCalculator( ) ;
nc.setFactory(new DebugNegationExpressionFactory(nc.getFactory( ) ) ) ;
nc.calculate( ) }
Listing 4.9: Main for the advanced calculator with debug functionality
ThisDebugNegationExpressionFactoryapplies the factory provided by one of the Cal-culators. It serves as delegate to createExpressioninstances. Listing 4.10 sketches one of the create methods. This ensures that the evaluation functionality is implemented only once.
public Constant createConstant(int c) {
Constant cons = this.delegate.createConstant(c) ; return new DebugConstant(cons) ;
}
Listing 4.10: Snippet from the expression factory implementation for the advanced calculator with debug functionality
Also applying delegation, these instances are wrapped inDebugExpressioninstances.
Before theevaluate()method of the delegate is called, the desired output is generated.
An example implementation is sketched in Listing 4.11.
public DebugConstant implements Constant { public DebugConstant(Constant delegate) {
this.delegate = delegate; }
public int eval( ) {
this.printToDebugStream(delegate) ; return this.delegate.eval( ) ;
} }
Listing 4.11: Implementation of DebugConstant for the advanced calculator To extend the simple calculator behaviorally, one starts to implement from scratch. The
Findings
eval()method has not to be reimplemented as it can be inherited via class inheritance.
In contrast, the behavioral extension of the advanced calculator only requires a factory.
The factory can be applied to a calculator by a customizedmain()method in that also the concrete calculator implementation is specified. Both calculators of the advanced design, i.e.,ExtensibleCalculatororNegationCalculator, can be used with the same factory implementation.
Horizontal extension: Print
As an example for a horizontal extension aprint()method shall be added toExpression API Breaking
and all subtypes. This implies that all implementations that subtypeExpressionhave to be modified. If all source code is available and modifiable, this can be realized with some effort. Otherwise, the change breaks API – theApplication Programming Interface that defines access to a software component.
An API break can be avoided. The type definition for Expression is extended by a
No API Breaking
subtypePrintExpression. Theprint() method is specified in this subtype. Applying this to all other subtypes ofExpressionresults in the type hierarchy shown in Fig. 4.5a.
One can observe, that multiple inheritance is required — at least for the definitions of the types.
The simple calculator design uses only one Java-interface,Expression. All other types
Simple Design
are defined by classes and do not support multiple inheritance. Thus, to implement the print extension in a non API breaking fashion, some of the methods and classes must be reimplemented from scratch. Similar to the behavioral extension, debug, thecalculate ()method has to be reimplemented. Within the method the objects implementing the print functionality have to be instantiated. Thereby, the specific calculator is specified and can not be changed without further reimplementation.
(a) Non API breaking type hierarchy for the print exten-sion
(b) Factories for the advanced design
Figure 4.5.: Horizontal extension: print, advanced calculator
When the print extension is implemented, the design of the advanced calculator pays off. The type hierarchy depicted in Fig. 4.5a can be implemented 1 : 1 as
Java-Advanced Design
interfaces are used consequently. ExpressionFactory is extended by a Java-interface PrintExpressionFactory, see Fig. 4.5b. The factory methods of this Java-interface re-turn subtypes ofPrintExpression. Classes that implement the new print Java-interfaces can make use of delegation. An implementation of thePrintExpressionFactorycan be used with all existing calculators. Code that does not need the print functionality is not affected.
Modules that require the print functionality have to ensure that an instance of Print ExpressionFactory is set in the calculator, before any object is created. Then, they can cast the objects of type Expression created by any ExpressionFactory to Print-Expressionand use the newprint()method. One may argue that this cast exhibits some bad smell of code. However, print is an extension to the original calculator. The API of the original calculator never pretended to support a print method for expressions.
If the print method is required, one refers to the extended API. The cast expresses this requirement and fails if it is not met.