Clean code Tips1:: Urge to put comments? refrain to do it.


While you are writing code, assume you are writing a novel and your fellow coders is a reader of your novel, so anytime you think you have to put comment that means something wrong, you cant express yourselves through code. A real clean code does not need comments.


I know it is provocative to put complex business logic in plain English to easily explain the logic,  or Jira id/bug Id as a future reference in the codebase, but with time, the codebase evolves, methods are refactored but we forgot to refactor comments and your comment will be out of sync and gives a wrong interpretation about the method/code/business logic, undoubtedly a code smell,  if you need to put bug id for future reference put as a commit message but avoid comments remember clean code is self-explanatory.

Toss out Inheritance Forest

Toss out Inheritance Forest

In the previous article, we saw How we can solve the Inheritance forest problem by Decorator pattern,
In case if you missed that Article you can go here::

For who does not like to click the link while reading an Article, I just quickly state the Problem statement.

Problem Statement:
We have to create a ball and same can be made by any materials and can have any color.
So here, two constraints are

A ball can be made by any material (Rubber, plastic, Polythene, Feather, Leather, Leather-Rubber etc.).
Can be any color (Red, Orange, Blue, Yellow, Blue-Yellow etc).
Now, the ball can be any combination of material and color.(Red Rubber Ball, Yellow Rubber Ball etc).

Choosing Design Pattern :

To see the problem one thing is sure Ball’s material and Ball’s color are the variable parts here and it can have any possible values and the second part of the problem statement is it can be any combinations of material and color, technically any combination of two variable parts.

So the crux of the problem is if we create a child class which implements IColor, IMaterial interfaces then for each possible combinations we have to create a concrete class as an outcome creates  Inheritance Forest.

Challenges:
So we have to design our problem in such a way where we can supply the variable parts from outside or technically caller of our design can choose the material and color runtime and pass the same into our framework.

In a generic way  most of the use cases follow the same context, In Functional programming, we can do it through Higher order function where we can pass a function as an argument and that function holds the computation logic.

In Java, we can achieve it through IOC Where Higher level component talk to lower level components via an Interface,

Lower level component holds the strategy implementation and we pass them to Higher order components which hold the Algorithm.

we can achieve it through Strategy Pattern.



Strategy pattern :

According to Wikipedia definition , In computer programming, the strategy pattern (also known as the policy pattern) is a behavioural software design pattern that enables an algorithm's behavior to be selected at runtime.
So by using Strategy pattern, we can push Material and Color into ball creation algorithm as behavior/strategy can be pushed at runtime so we can create different combinations also.

Let See the diagram

Expel Inheritance forest by Strategy pattern





Here I create two interfaces called IColor and IMaterial, each has own concrete implementations Now High-Level components talks to lower level through those interfaces and caller of the program choose one of the implementations of interfaces and pass them to Higher level components for the algorithm computation.

Let see How the code look likes

IColor.java

package com.example.strategy;

public interface IColor {

   public String createColor();

}

IMaterial.java

package com.example.strategy;

public interface IMaterial {
   
   public String createMaterial();

}

Now the Higher Order Component

BallManager.java

package com.example.strategy;

public class BallManager {
   
   IColor color;
   IMaterial material;
   
   public void setColor(IColor color) {
      this.color = color;
   }


   public void setMaterial(IMaterial material) {
      this.material = material;
   }



   public void createBall(){
      String colorStr = color.createColor();
      String materialStr = material.createMaterial();
      displayInfo(colorStr,materialStr);
     
   }
   private void displayInfo(String... strings){
      System.out.println("Add Ball Color ::" + strings[0] );
      System.out.println("Add Ball material ::" + strings[1] );
      System.out.println("Produce the Ball");
   }

}


Client of Our framework creates Actual implementation on the fly.

Caller.java

package com.example.strategy;

public class Caller {
   public static void main(String[] args) {
     
      IColor redColor = new IColor(){

          @Override
          public String createColor() {
              return "Red";
          }
         
      };
     
      IColor blueColor = new IColor(){

          @Override
          public String createColor() {
              return "Blue";
          }
         
      };
     
      IMaterial plasticMaterial = new IMaterial(){

          @Override
          public String createMaterial() {
              return "Plastic";
          }
         
      };
     
     
      BallManager mgr = new BallManager();
      mgr.setColor(blueColor);
      mgr.setMaterial(plasticMaterial);
      mgr.createBall();
      System.out.println("=====================");
      mgr.setColor(redColor);
      mgr.setMaterial(plasticMaterial);
      mgr.createBall();
   }

}


Output:

Add Ball Color ::Blue
Add Ball material ::Plastic
Produce the Ball
=====================
Add Ball Color ::Red
Add Ball material ::Plastic
Produce the Ball

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.