Code of Shadows:Mastering Decorator Pattern in Java – Po & Shifu’s Thriller Story of Clean Code

 


The Logging Conspiracy 

It was a cold, misty morning at the Jade Palace. The silence was broken not by combat… but by a mysterious glitch in the logs.

Po (rushing in): "Shifu! The logs… they're missing timestamps!"

Shifu (narrowing his eyes): "This is no accident, Po. This is a breach in the sacred code path. The timekeeper has been silenced."

Traditional OOP Decorator

Shifu unfurled an old Java scroll:

//Interface
package com.javaonfly.designpatterns.decorator.oops;
public interface Loggable {

public void logMessage(String message);
}
//Implementation
package com.javaonfly.designpatterns.decorator.oops.impl;
import com.javaonfly.designpatterns.decorator.oops.Loggable;
public class SimpleLogger implements Loggable {
@Override
public void logMessage(String message) {
System.out.println(message);
}
}
//Implementation
class TimestampLogger implements Loggable {
private Loggable wrapped;

public TimestampLogger(Loggable wrapped) {
this.wrapped = wrapped;
}

public void logMessage(String message) {
String timestamped = "[" + System.currentTimeMillis() + "] " + message;
wrapped.logMessage(timestamped);
}
}

//Calling the decorator
public class Logger {
public static void main(String[] args){
Loggable simpleLogger = new SimpleLogger();
simpleLogger.logMessage("This is a simple log message.");

Loggable timestampedLogger = new TimestampLogger(simpleLogger);
timestampedLogger.logMessage("This is a timestamped log message.");
}
}
//Output
This is a simple log message.
[1748594769477] This is a timestamped log message.

Po: "Wait, we’re creating all these classes just to add a timestamp?"

Shifu: "That is the illusion of control. Each wrapper adds bulk. True elegance lies in Functional Programming."

Functional Decorator Pattern with Lambdas

Shifu waved his staff and rewrote the scroll:

package com.javaonfly.designpatterns.decorator.fp;

import java.time.LocalDateTime;
import java.util.function.Function;

public class Logger {
  //higer order function
    public void decoratedLogMessage(Function<String, String> simpleLogger, Function<String, String> timestampLogger) {
        String message = simpleLogger.andThen(timestampLogger).apply("This is a log message.");
        System.out.println(message);
    }

    public static void main(String[] args){
        Logger logger = new Logger();

        Function<String, String> simpleLogger = message -> {
            System.out.println(message);
            return message;
        };

        Function<String, String> timestampLogger = message -> {
            String timestampedMessage =  "[" + System.currentTimeMillis() + "] " + ": " + message;
            return timestampedMessage;
        };

        logger.decoratedLogMessage(simpleLogger, timestampLogger);
    }
}
//Output
This is a log message.
[1748595357335] This is a log message.

Po (blinking): "So... no more wrappers, just function transformers?"

Shifu (nodding wisely): "Yes, Po. In Functional Programming, functions are first-class citizens. The Function<T, R> interface lets us compose behavior. Each transformation can be chained using andThen, like stacking skills in Kung Fu."

Breaking Down the Code – Functional Wisdom Explained

Po (scratching his head): "Shifu, what exactly is this Function<T, R> thing? Is it some kind of scroll?"

Shifu (gently): "Ah, Po. It is not a scroll. It is a powerful interface from the java.util.function package—a tool forged in the fires of Java 8."

"Function<T, R> represents a function that accepts an input of type T and produces a result of type R."

In our case:

Java
 
Function<String, String> simpleLogger

This means: “Take a String message, and return a modified String message.”

Each logger lambda—like simpleLogger and timestampLogger—does exactly that.

The Art of Composition — andThen

Po (eyes wide): "But how do they all work together? Like… kung fu moves in a combo?"

Shifu (smiling): "Yes. That combo is called composition. And the technique is called andThen."

Java
 
simpleLogger.andThen(timestampLogger)

This means:

  1. First, execute simpleLogger, which prints the message and passes it on.

  2. Then, take the result and pass it to timestampLogger, which adds the timestamp.

This is function chaining—the essence of functional design.

String message = simpleLogger
.andThen(timestampLogger)
.apply("This is a log message.");

Like chaining martial arts techniques, each function passes its result to the next—clean, fluid, precise.

Po: "So the message flows through each function like a river through stones?"

Shifu: "Exactly. That is the way of the Stream."

Functional Flow vs OOP Structure

Shifu (serenely): "Po, unlike the OOP approach where you must wrap one class inside another—creating bulky layers—the functional approach lets you decorate behavior on the fly, without classes or inheritance."

  • No need to create SimpleLoggerTimestampLogger, or interfaces.

  • Just use Function<String, String> lambdas and compose them.

The Secret to Clean Code

“A true master does not add weight to power. He adds precision to purpose.” – Master Shifu

This approach:

  • Eliminates boilerplate.
  • Encourages reusability.
  • Enables testability (each function can be unit-tested in isolation).
  • Supports dynamic behavior chaining.

Po's New Move: Making the Logger Generic

After mastering the basics, Po's eyes sparkled with curiosity.

Po: "Shifu, what if I want this technique to work with any type—not just strings?"

Shifu (with a deep breath): "Yes of course you can ! Try to write it, Dragon warrior."

Po meditated for a moment, and then rewrote the logger:

 public <T> void decoratedLogMessage(Function<T, T>... loggers) {
        Function<T, T> pipeline= Arrays.stream(loggers).sequential().reduce(Function.identity(), Function::andThen);
        T message = pipeline.apply((T) "This is a log message.");
        System.out.println(message);
    }
Po (bowing):
"Master Shifu, after learning to compose logging functions using 
Function<String, String>, I asked myself — what if I could decorate not just strings, but any type of data? Numbers, objects, anything! So I used generics and built this move..."

public <T> void decoratedLogMessage(Function<T, T>... loggers) 
"This declares a generic method where T can be any type — StringInteger, or even a custom User object.
The method takes a 
varargs of Function<T, T> — that means a flexible number of functions that take and return the same type."

Function<T, T> pipeline=
  Arrays.stream(loggers).sequential().reduce(Function.identity(), Function::andThen);
  • "I stream all the logger functions and reduce them into a single pipeline function using Function::andThen.

    • Function.identity() is the neutral starting point — like standing still before striking.

    • Function::andThen chains each logger — like chaining combos in kung fu!"

  • T message = pipeline.apply((T) "This is a log message.");
    

    I apply the final pipeline function to a sample input.
    Since this time I tested it with a String, I cast it as (T). But this method can now accept any type!"

    Shifu (smiling, eyes narrowing with pride):
    "You’ve taken the form beyond its scroll, Po. You have learned not just to use functions—but to respect their essence. This generic version... is the true Dragon Scroll of the Decorator."

    Modified Code by Po

  • package com.javaonfly.designpatterns.decorator.fp;
    
    import java.time.LocalDateTime;
    import java.util.Arrays;
    import java.util.function.Function;
    
    public class Logger {  
        public <T> void decoratedLogMessage(Function<T, T>... loggers) {
            Function<T, T> pipeline= Arrays.stream(loggers).sequential().reduce(Function.identity(), Function::andThen);
            T message = pipeline.apply((T) "This is a log message.");
            System.out.println(message);
        }
    
        public static void main(String[] args){
            Logger logger = new Logger();
            Function<String, String> simpleLogger = message -> {
                System.out.println(message);
                return message;
            };
    
            Function<String, String> timestampLogger = message -> {
                String timestampedMessage =  "[" + System.currentTimeMillis() + "] " + message;
                return timestampedMessage;
            };
            Function<String, String> JadeLogger = message -> {
                String JadeLoggedMessage =  "[jadelog] " + message;
                return JadeLoggedMessage;
            };
       
            logger.decoratedLogMessage(simpleLogger, timestampLogger,JadeLogger);
        }
    }
    //Output
    This is a log message.
    [jadelog] [1748598136677] This is a log message.

  • Wisdom Scroll: OOP vs Functional Decorator

    FeatureOOP DecoratorFunctional Decorator
    Needs ClassYesNo
    Uses InterfaceYesOptional
    ComposabilityRigidElegant
    BoilerplateHighMinimal
    FlexibilityModerateHigh (thanks to lambdas)


Final Words from Master Shifu

"Po, the world of code is full of distractions—designs that look powerful but slow us down. A true Kung Fu developer learns to adapt. To decorate without weight. To enhance without inheritance. To flow with functions, not fight the structure."


Part 1- Kung Fu Code: Master Shifu Teaches Strategy Pattern to Po – the Functional Way!

Get rid of Inheritance Forest: Part 1

Get rid of Inheritance Forest

While doing code review, I have seen many times that there is a potential danger of creating a lot of inherited classes, meaning a simple change in business requirements may make things unmanageable. So, surely, this is a serious code smell, and we must take action.

One of the business cases comes in my mind is.

Business Case
If criteria are interlinked, the outcome product can be any combination of those criteria.
To put it simply, say the requirement is:

 "We have to create a ball, and the ball can glow-in-the-dark, and/or it can be printed with a smiley, and/or it can be scented, etc."

So here, the two main criteria would be:

  1.  A ball can be decorated with (glow-in-the-dark properties, a smiley, scented, etc.)
   2. It can have any combination of the above properties like (a Disco-Light smiley ball, a smiley Sandalwood scented  ball, a glow-in-the-dark Rosy scented ball, etc.)

According to the requirements, If we try to solve the problem by create interfaces for each decoration:
IGlowinthedark
ISmiley
IScent
And then create a concrete product that implements either or all of the interfaces as per requirements and then implement the each interfaces method.

The design seems to be right in naked eye, as it maintains the "coding to an interface" principle and welcomes the future changes as well!

Fig 1: Multiple Inheritance

But, is it well designed?
Put your thinking cap on, before reading the next part of the article. 

In my opinion, most of the time this would not be considered a good design for this application. So, let me explain my reasoning...

The Problem
This design very poorly handles decorations. Why? Say we have n number of decorators (Glow-in-the-dark, Smiley, Scented, etc).  each has m number of implenetation So, there will be Cn(C(m)) possible combinations.

Each decorator has multiple implementation like 

IGlowinthedark can have Disco Lights, Led Light etc
ISmiley can have Happy meme,ROFL meme etc
IScent has different fragrances like Sandalwood,Rose etc.

When n and m is small, there is a relatively small number of combinations. But what if n and m is a large number? How many combinations are there then?

We'd need to create a concrete class for each possible combination, so if the total number of combinations of (n,m) are 1,000, then we have to create 1,000 concrete classes to satisfy all these different combinations, like a Disco-light smiley ball, a smiley Sandalwood scented  ball, a glow-in-the-dark Rosy scented ball, etc.  etc.)

This is a massive failure of our chosen design. Our code base will be large and unmanageable. Somehow, we need to deal with the combination problem—we need to change our design.

GOF to the Rescue
Can you guess which GOF patterns will rescue us? Take a look at the picture below for reference.

Can you find the pattern?

If you guessed Decorator then congratulations, you are correct! This pattern will rescue us from this scenario. There are many other Solution by which we can get rid of this problem in later tutorials I will discuss about other solutions.

But before we get to that, let's discuss why our previous design fails.

If we read the requirements minutely, we would understand that the complexity lies in creating the many different combinations of the decorators of the ball. Through inheritance, one concrete class describes only one possible combination, as its implements either or all (IGlowinthedark and ISmiley or IScent) so it is static in nature.

The combination is proportional to the number of concrete classes, so concrete classes linearly increase as the combination increases. Our main failure lies in failing to dynamically create combinations. As it is, the outcome creates an Inheritance Forest, which is ever-expanding as these combinations/individual implementation grow in number.

It is like printing 1,000 array elements manually without using any loop.

To solve this riddle we are searching for a way to create a dynamic combination to expel the Inheritance Forest. So, all problems boil down to the following question: How can we push combination/behavior runtime dynamically?

The Decorator Pattern
The intent of the Decorator pattern is to add responsibility/behavior at runtime to an Object. That's exactly the answer we're searching for.

How Decorator Works
In the Decorator pattern, we encapsulate the main/core object inside a wrapper interface. In this case, the main Object is Ball and the interface is IBall. Now, every responsibility/behavior/criteria also implements the same Interface IBall. In our case, Glow-in-the-dark, Smiley, Scent implement IBall as well. And we have a composition with the same interface (IBall), which acts as a Wrapper Object.

Through this technique, we can achieve two things:

1. Any component that implements IBall has a (HAS-A) relationship with another component that also implements IBall. Through this, we can associate any component with another and achieve dynamic behaviors.

2. One component performs its work, then delegates the work to its associated (HAS-A) component. Again, that component follows the same pattern, which creates a delegator chain. At last, it produces a concrete product made by any combination.



Let see the Diagram of Decorator
Fig 2: Decorator Pattern





.
Coding :

Enough theory now see How to achieve run time behaviors through decorator





Decorator Interface:

public interface IBall {
   
    public void createBall();

}


Core Component :
Now create the core component which is the base, on top of it will add behavior as wrapper Object.



package com.example.decorator;
public class CoreBall implements IBall{

    IBall wrappeBall;
    public CoreBall(IBall wrappeBall){
        this.wrappeBall=wrappeBall;
    }

    @Override
    public void createBall() {
    System.out.println("Ball creation End");
    if(wrappeBall !=null)
    wrappeBall.createBall();
    }

}


Wrapper Components:

Now we will create main wrapper Component like Colors of Ball (Red,Blue,Green) and materials of the ball (Rubber,Polythene,Plastic etc.) So we can create any combinations by using them.

Light.java
package com.example.decorator;

public class Light implements IBall {
    IBall wrappeBall;
    public Light(IBall wrappeBall) {
        this.wrappeBall = wrappeBall;
    }
    @Override
    public void createBall() {
        System.out.println("Decorate with Disco Light");
        if(wrappeBall !=null)
        wrappeBall.createBall();
    }
}
Smiley.java

package com.example.decorator;
public class Smiley implements IBall{
    IBall wrappeBall;

    public Smiley(IBall wrappeBall) {
        this.wrappeBall = wrappeBall;
    }

    @Override
    public void createBall() {
        System.out.println("Decorate with Happy Smiley");
        if(wrappeBall !=null)
        wrappeBall.createBall();
    }
}




Test:

No we will create Multiple combinations on the fly as each component implements IBall interface and expect a IBall interface as argument of constructor so we can pass any components into any other components.


Main.java

package com.example.decorator;

/**
* @author Shamik Mitra
*
*/
public class Main {
    public static void main(String args[]) {
        IBall ball = new Smiley(new Light(new Ball(null)));
        ball.createBall();
        System.out.println("*********");
       }
}

Output :

Decorate with Disco Light

Decorate with Smiley

Ball creation End

*********


TIP: we have learned that Decorator can create multiple combinations by delegating responsibilities so if there is a requirement where two or more constraints can combine with each other to make a new product we can think of Decorator and not going for Multiple Inheritance.