Decorator Pattern: Introduction

Transcription

1 Consider the following situation: Decorator Pattern: Introduction You have a set of subclasses (Subclass1, Subclass2, ) that represent variations of some superclass (Superclass) As usual, the subclasses vary from one another in one way or another, but share common characteristics and behaviors There is some function that all of the subclasses perform, but which is dependent on the particular subclass Suppose there are features (F eature1, F eature2, ) that modify the function whose effects are independent of the subclasses I.e., a feature can be applied to the function no matter in which of the subclasses the function is being performed The feature will affect the outcome of the function the same way regardless of which subclass performs the function A naive approach to implementing this situation would be to create a new subclass for each combination of a subclass with these modifiers 1

2 Decorator Pattern: Introduction (2) This result is referred to as class explosion for obvious reasons 2

3 Decorator Pattern: Introduction (3) An alternative is to 1. Include a Boolean value for each feature in the superclass 2. Include a conditional in the function at the superclass level that checks to see whether a particular feature is included At the superclass level, the function computes the effect of only the features added to a given subclass At the subclass level, the function is over-ridden to compute the base effect of the function as it applies to that class only, without considering any features It then calls the function at the superclass level to incorporate the features into the result already computed at the subclass level This requires appropriate set and querying methods for each feature (at the superclass level) This eliminates the class explosion seen in the initial approach 3

4 Skeleton code: Decorator Pattern: Introduction (4) public class Superclass private boolean feature1 = false; private boolean feature2 = false; private boolean feature3 = false; private result; //Result of common function public boolean hasfeature1() return feature1; public boolean hasfeature2() return feature1; public void setfeature1() feature1 = true; public void setfeature2() feature2 = true; public commonfunction() if (hasfeature1()) result = feature1computation(); if (hasfeature2()) result = feature2computation(result); if (hasfeature3()) result = feature3computation(result); public class Subclass1 extends Superclass public commonfunction() return subclass1computation(super.commonfunction); 4

5 Subclass1 object1 = new Subclass1(); XXX result; object1.setfeature2(); object1.setfeature5(); result = object1.commonfunction(); Decorator Pattern: Introduction (5) This approach introduces a lot of potential for unwanted code modification: 1. If a feature s computation changes, changes will be made in the superclass 2. New features require modification of the superclass (instance vars, commonf uncti 3. Existing features may not be applicable to newly-added subclasses, but the subclasses will inherit associated methods anyway 5

6 Decorator Pattern: Open-Closed Design Principle Design Principle 4 (Open-Closed Principle) Classes shuld be open for extension, but closed for modification. Goal is to 1. Prevent modification of existing code Precludes introduction of bugs 2. Allow addition of new behavior without modification of existing code, via extensions While this ideal may be able to be applied to every piece of code, want to apply with respect to those parts that are most likely to change This approach adds complexity to code by adding additional levels of abstraction, and if applied to the n th degree, will result in code that s hard to read 6

7 Decorator Pattern: Defined Decorator Pattern: Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Decorators (the features in the above example) act as wrappers for our subclass objects Each decorator will have an instance variable that holds a reference to what it wraps Decorators inherit from the same superclass as the subclasses Since every feature inherits from the same superclass, decorators can nest Since they all inherit from the same superclass, decorators inherit the common function shared by the subclasses As a result, we can implement a chain of nested calls to the common function The decorator can apply its behavior before or after delegating to the wrapped object 7

8 Decorators can be added dynamically Example code: public abstract class Superclass //General methods Decorator Pattern: Defined (2) public abstract commonfunction(); public abstract class FeatureDecorator extends Superclass //Over-ride general methods public class Subclass1 extends Superclass public Subclass1() //Initialize public commonfunction() //Processing specific to this subclass public class Feature1 extends FeatureDecorator Superclass wrappedobject; public Feature1(Superclass wrappedobject) this.wrappedobject = wrappedobject; public double commonfunction() return //composition of this method s computation and wrappedobject.commonfunction(); 8

9 public class Driver public static void main(string args[]) Superclass object1 = new Subclass1(); object1.commonfunction()); Superclass object2 = new Subclass2(); object2 = new Feature1(object2); object2 = new Feature1(object2); object2 = new Feature3(object2); object2.commonfunction()); Decorator Pattern: Defined (3) 9

10 Decorator Pattern: Inheritance v Composition The inheritance of the decorators from the superclass is done so that subclasses and the decorators have the same type This provides no new behavior for the subclasses New behavior is achieved by the composition of the subclasses and decorators Decorators can be added at any time to add new behavior This will not affect the existing code of the subclasses 10

11 Decorator Pattern: Cautions Code that relies on a subclass s type can be broken by decorators Decorators increase the number of objects, thereby increasing the chance for error 11