In this post we are going to look at a couple of examples which use the GoF Decorator pattern. We will then refactor this code to use some of the features introduced in Java 8 which give Java a taste of functional programming. After this refactoring, we will see if the refactored code showcasing the decorator pattern becomes concise and easy to understand or makes it more complicated.
The basic idea behind the decorator pattern is that it allows us to add behavior to an object without affecting or modifying the interface of the class. I would suggest you to read and get a basic idea about the Decorator pattern in case you are completely unaware of it.
I would be considering 2 existing posts showcasing the decorator pattern and then we would be refactoring the code using Java 8.
Typical Decorator – Example one
The first example that we are going to look at is a code sample that I saw from a site, codeofdoom.com, which unfortunately does not exist anymore(domain seems to have expired). That post referred to an example which was simple to read and showed how a typical decorator pattern is implemented. I thought I had understood the pattern but I was mistaken.
The requirement in that example
The requirement that I understood from the code – We need to format a particular text supplied as input. The formatting can be one of several options- we return the text as it is, format the text to upper case, replace a word in the text with another word , concatenation of text with another string or a permutation and combination of the options. I have stated the requirements upfront but usually as developers we are never aware of the requirements upfront and requirements always keep changing. It would not make sense to create separate classes for each permutation – combination. In such situations, the decorator pattern can be extremely useful.
The example mentioned has an interface Text and a basic implementation of the same which returns the text. There are 3 classes AllCaps, StringConcat and ReplaceThisWithThat which are decorators taking the input text and adding specific behavior to it. The advantage of using the decorator pattern here is that we can use and combine 1 or more decorators to achieve formatting of the input text dynamically rather than sub-classing and creating different combinations of the sub-classes.However the implementation of a typical decorator is not so straightforward to understand. I had to debug a little bit to get a good understanding of how the code really decorates the object.
So let’s define an interface Text with a method format as shown below –
public interface Text {
public String format(String s);
}
The BaseText class simply returns the text as is –
public class BaseText implements Text{
public String format(String s){
return s;
}
}
The TextDecorator class serves as base decorator class which other classes extend. This decorator class is like a core class which helps in combining different functionalities.
public abstract class TextDecorator implements Text {
private Text text;
public TextDecorator(Text text) {
this.text = text;
}
public abstract String format(String s);
}
The AllCaps class takes the input and formats it to uppercase –
public class AllCaps extends TextDecorator{
public AllCaps(Text text){
super(text);
}
public String format(String s){
return text.format(s).toUpperCase();
}
}
The StringConcat class calls format and then concatenates the input string –
public class StringConcat extends TextDecorator{
public StringConcat(Text text){
super(text);
}
public String format(String s){
return text.format(s).concat(s);
}
}
And finally, the class which replaces text “this” with “that” –
public class ReplaceThisWithThat extends TextDecorator{
public ReplaceThisWithThat(Text text){
super(text);
}
public String format(String s){
return text.format(s).replaceAll("this","that");
}
}
Test class to run the decorators –
public class TextDecoratorRunner{
public static void main(String args[]){
Text baseText = new BaseText();
Text t = new ReplaceThisWithThat(new StringConcat(new AllCaps(baseText)) );
System.out.println(t.format("this is some random text"));
}
}
Notice how the call is done. It is actually inside-out but the code is read from the outside-in.
A pixel is worth 1024 bits
The left hand side shows the calls to the format method in each decorator class and the right hand side shows how the decorators hold references or how they are chained.
The final output from this is – THIS IS SOME RANDOM TEXTthat is some random text.
Refactoring the decorator pattern using Java 8
Well, now to the main task of re-implementing the same using functional style. The BaseText class shown above has a function, format, which simply takes a String and returns a String. This can be represented using functional interface, Function<String,String> – introduced in Java 8.
import java.util.function.Function;
public class BaseText implements Function<String,String>{
public BaseText(){
}
@Override
public String apply(String t) {
return t;
}
}
Now, each decorator class implements a simple functionality of formatting a string in different ways and can be combined as shown below in a single class using static methods.
public class TextDecorators
{
public static String allCaps(String s){
return s.toUpperCase();
}
public static String concat(String input) {
return input.concat("this is some random text");
}
public static String thisWithWhat(String input) {
return input.replaceAll("this", "that");
}
}
This simply leads us to the following –
public class TextDecoratorRunner {
public static void main(String[] args) {
String finalString = new BaseText()
.andThen(TextDecorators::allCaps)
.andThen(TextDecorators::concat)
.andThen(TextDecorators::thisWithWhat)
.apply("this is some random text");
System.out.println(finalString);
}
}
The code above does function chaining and uses method reference. It takes the text and passes it through a chain of functions which act as decorators. Each function applies a decoration and passes the decorated string as output to the next function which treats it as an input. In this scenario, there is no need to have separate classes which act as decorators or the abstract base class. This implementation offers the same flexibility as the typical solution but I think it is also much much easier to understand as compared to the typical way of implementing the decorator pattern. There is also no inside-out or outside-in business when we call the function.
Typical Decorator – Example two
The second example that we are going to consider is shown here groovy decorator. I would suggest you to read it to get a basic understanding of the use case. Also note the confusion between whether the complete text is logged in upper case or timestamp is logged in lower case.
Decorator pattern refactored
Let us try and use the same concept of function chaining to refactor this.
The code for the Logger interface would look like this –
public interface Logger {
public void log(String message);
}
The SimpleLogger class –
public class SimpleLogger implements Logger {
@Override
public void log(String message) {
System.out.println(message);
}
}
The individual decorated logger can be represented as below –
import java.util.Calendar;
public class Loggers {
public static String withTimeStamp(String message){
Calendar now = Calendar.getInstance();
return now.getTime() + ": "+ message;
}
public static String uppperCase(String message){
return message.toUpperCase();
}
}
And finally using function chaining –
import java.util.function.Function;
import java.util.stream.Stream;
public class LoggerTest {
public static void main(String[] args) {
Logger logger = new SimpleLogger();
Function<String,String> decorators = Stream.<Function<String,String>>of(Loggers::withTimeStamp,Loggers::uppperCase)
.reduce(Function.identity(),Function::andThen);
logger.log(decorators.apply("G'day Mate"));
}
}
The code above looks a little daunting at first glance but it is actually simple, let us break it down –
Lines 9- 12 are the key to understanding this. I am using Stream.of and passing method references which are individual decorators.
- To combine them or to chain them, we use the Stream.of. The Function<String,String> in Stream.<Function<String,String>>of is more of a compilation thing , to represent the Stream that the output is a Function<String,String>. Using the Stream.of, we are forming a chain of functions.
- Now to the reduce part, the reduce part chains all of them together to form a single function. What do we want to do with each function as they come out from the stream ? We want to combine them, this is done using the andThen, that is exactly done in the 2nd parameter to the reduce function. The first parameter to the reduce method is an initial value, this is the identity function – given a function, just return the function. Every reduction needs a starting point. In this case, the starting point is the function itself.
- The chaining yields a Function<String,String> decorators.
- We just call the apply method to this using the parameter G’day Mate which passes it through the chain of functions( decorators) and finally sends that to the logger.log method.
This version of the decorator pattern is easier to understand, we simply took a message, added the timestamp to it , converted it to upper case and logged it.The Stream.of and the methods references being passed to it might seem difficult at the first read, but trust me it is more of a new way of solving the problem and an easier one in my opinion.
Conclusion
We took 2 examples of the decorator pattern but both examples have clarified that there is certainly an easier and better way to implement the decorator pattern. In both cases the decorator pattern using the functional style is definitely more concise and easier to understand. Code that is easier to understand is always easy to maintain. Can we safely conclude that we probably don’t need the typical decorator pattern anymore?
Well, in the examples that we considered, we had just one method or one functionality to decorate, the format method in the first example and log method in the second example. In these scenarios, the functional style definitely seems better and there is no need to go about creating different classes, the abstract class and then use the cryptic way of calling them. But what if we had more than a single method to decorate ? This is something that needs to be looked at and I will try and answer that in another post.
Memoirs of a Software developer 