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 SimpleLogger, TimestampLogger, 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 — String, Integer, 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
  Feature
  OOP Decorator
  Functional Decorator
  Needs Class
  Yes
  No
  Uses Interface
  Yes
  Optional
  Composability
  Rigid
  Elegant
  Boilerplate
  High
  Minimal
  Flexibility
  Moderate
  High (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!

Read more

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

 "There is no good or bad code . But how you write it… that makes all the difference.”-- Master Shifu

The sun had just touched the tips of the Valley of Peace. Birds chirped, the wind whispered tales of warriors, and Po—the Dragon Warrior—was busy trying to write some Java code. Yes, you read that right.

Master Shifu stood behind him, watching, amused and concerned.

Po (scratching his head): “Master Shifu, I’m trying to make this app where each Kung Fu move is chosen based on the enemy. But the code is… bloated. Classes everywhere. If OOP was noodles, this is a full buffet.”

Shifu (calmly sipping tea): “Ah, the classic Strategy Pattern. But there’s a better way, Po… a functional way. Let me show you the path.”

The Traditional (OOP) Strategy Pattern – Heavy Like Po’s Lunch   

Po wants to choose a fighting strategy based on his opponent.

// Strategy Interface
interface FightStrategy {
    void fight();
}

// Concrete Strategies
class TigerFightStrategy implements FightStrategy {
    public void fight() {
        System.out.println("Attack with swift tiger strikes!");
    }
}

class MonkeyFightStrategy implements FightStrategy {
    public void fight() {
        System.out.println("Use agile monkey flips!");
    }
}

// Context
class Warrior {
    private FightStrategy strategy;

    public Warrior(FightStrategy strategy) {
        this.strategy = strategy;
    }

    public void fight() {
        strategy.fight();
    }

    public void setStrategy(FightStrategy strategy) {
        this.strategy = strategy;
    }
}

Usage

Warrior po = new Warrior(new TigerFightStrategy());
po.fight();  // Output: Attack with swift tiger strikes!

po.setStrategy(new MonkeyFightStrategy());
po.fight();  // Output: Use agile monkey flips!

Why This Is a Problem (and Why Po Is Annoyed)

Po: “So many files, interfaces, boilerplate! All I want is to change moves easily. This feels like trying to meditate with a noodle cart passing by!”

Indeed, OOP Strategy pattern works, but it's verbose, rigid, and unnecessarily class-heavy. It violates the spirit of quick Kung Fu adaptability!

Enter Functional Programming – The Way of Inner Simplicity

Shifu (nodding): “Po, what if I told you… that functions themselves can be passed around like scrolls of wisdom?”  

Po: “Whoa... like… JScrolls? 

Shifu: “No, Po. Java lambdas.” 

In functional programming, functions are first-class citizens. You don’t need classes to wrap behavior. You can pass behavior directly.

Higher-Order Functions – functions that take other functions as parameters or return them.

Po, In Java8 onwards , now we can do that easily with the help of lambda, lambda can wrap the functionality and can be pass to another method as a parameter.

Strategy Pattern – The Functional Way in Java

import java.util.function.Consumer;
class Warrior {
    private Consumer<Void> strategy;

    public Warrior(Consumer<Void> strategy) {
        this.strategy = strategy;
    }

    public void fight() {
        strategy.accept(null);
    }

    public void setStrategy(Consumer<Void> strategy) {
        this.strategy = strategy;
    }
}

But there’s a better, cleaner way with just lambdas and no class at all.

import java.util.function.Supplier;

public class FunctionalStrategy {

    public static void main(String[] args) {
        // Each strategy is just a lambda
        Runnable tigerStyle = () -> System.out.println("Attack with swift tiger strikes!");
        Runnable monkeyStyle = () -> System.out.println("Use agile monkey flips!");
        Runnable pandaStyle = () -> System.out.println("Roll and belly-bounce!");

        // Fighter is a high-order function executor
        executeStrategy(tigerStyle);
        executeStrategy(monkeyStyle);
        executeStrategy(pandaStyle);
    }

    static void executeStrategy(Runnable strategy) {
        strategy.run();
    }
}

Shifu (with a gentle tone):

“Po, in the art of code—as in Kung Fu—not every move needs a name, nor every master a title. In our example, we summoned the ancient scroll of Runnable… a humble interface with but one method—run(). In Java8 , we called it Functional Interface.

Think of it as a silent warrior—it expects no inputs(parameters) , demands no rewards(return type), and yet, performs its duty when called.

Each fighting style—tiger, monkey, panda—was not wrapped in robes of classes, but flowed freely as lambdas.

And then, we had the executeStrategy() method…
a higher-order sensei.

It does not fight itself, Po. It simply receives the wisdom of a move—a function—and executes it when the time is right.

This… is the way of functional composition.
You do not command the move—you invite it.
You do not create many paths—you simply choose the next step.”

Benefits – As Clear As The Sacred Pool of Tears

• No extra interfaces or classes

•  Easily switch behaviors at runtime

• More readable, composable, and flexible

•  Promotes the power of behavior as data.

Real-World Example: Choosing Payment Strategy in an App

Map<String, Runnable> paymentStrategies = Map.of(
    "CARD", () -> System.out.println("Processing via Credit Card"),
    "UPI", () -> System.out.println("Processing via UPI"),
    "CASH", () -> System.out.println("Processing via Cash")
);

String chosen = "UPI";
paymentStrategies.get(chosen).run(); // Output: Processing via UPI

Po: “This is amazing! It’s like picking dumplings from a basket, but each dumpling is a deadly move.” 

Shifu: “Exactly. The Strategy   was never about the class, Po. It was about choosing the right move at the right moment… effortlessly.” 

One move=One lambda.

The good part is this lambda only holds the move details nothing else. So any warrior can master these moves , to apply the move unnecessary he does not need to reference a bounded object which wrapped this move in a boilerplate class.

Final Words of Wisdom  

“The strength of a great developer lies not in how many patterns they know… but in how effortlessly they flow between object thinking and function weaving to craft code that adapts like water, yet strikes like steel.”-- Master Shifu, on the Tao of Design Patterns.

Coming Up in the Series

• Part 2: Code of Shadows:Mastering Decorator Pattern in Java – Po & Shifu’s Thriller Story of Clean Code
• Part 3: The Command Pattern – When Po Orders Actions like Takeout .
• Part 4: Template Method – Recipes for Reuse and Inner Peace 
• Part 5: Filter Chain – Training Montage for Cleaner APIs

Read more