Toss Out the Inheritance Forest

Note from DZone: This article is generating a lot of discussion in the comments thread, so be sure to check those out when you're done with the article!

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.

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 properties, 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, we would try to solve the problem by creating interfaces for each decoration:

• IGlowintheDark
• ISmiley
• IScent

A concrete product that implements either or all of the interfaces as per requirements and then implements the interfaces method.

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

Take a look at the picture below for reference.

It seems to be right, 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 handles decorations very poorly. Why? Well, let's say we have n number of decorators (Glow-in-the-dark, Smiley, Scented, etc.) each has m number of implentations. So, there will be Cn(C(m)) possible combinations.

Each decorator has multiple implementations like: 

• IGlowinthedark can have Disco Lights or LED Lights, etc.
• ISmiley can have the generic Happy Meme or the ROFL Meme, etc.
• IScent has different fragrances like Sandalwood or 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 DiscoLight Smiley ball, a Smiley Sandalwood Scented ball, a Glow-in-the-Dark Rosy scented ball, etc.)

This is a massive failure of our chosen design. Our codebase 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?

If you guessed Decorator then congratulations, you are correct! This pattern will rescue us from this scenario. But before we get to Decorator, let's discuss why our previous design fails. (Quick Note: There are many other solutions we could use to get rid of this problem, and I plan talk about these solutions in later tutorials.)

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 implementations 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 the 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, DiscoLight, ROFL Smiley, Rosy 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 a diagram of our Decorator:

Coding

Enough theory — now see how to achieve the desired runtime behaviors through a Decorator pattern:

public interface IBall {  
    public void createBall();
}

Core Component

Now we create the core component, which is the base. On top of it, we will add behavior as a 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 decorator components, like Glowing Ball, Smiley (DiscoLight, LED Light, Happy Meme, etc.) so we can create any combination with them:

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();
    }
}

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

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

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

*********

Conclusion

We have learned that the Decorator pattern can create any combination by delegating responsibilities. So, if there is a requirement where two or more criteria can be combined with each other to produce a product, we can think of the Decorator pattern — not multiple inheritance.