Ferhat KUL: desing patterns and principles

Interface Segregation principle (ISP)

This principle is I of S.O.L.I.D design principles.

Interface Segregation Principle stats that a client should not implement an interface if it doesn’t use that. this happens mostly when one interface contains more than one functionality and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this desing principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Here is an easy to understand ISP example

Open Closed Principle (OCP)

This principle is O of S.O.L.I.D design principles.

According to Open Closed Principle, Software entities (Classes, modules, functions) should be OPEN for EXTENSION, CLOSED for MODIFICATION.

Lets try to reflect on the above statement- software entities once written shouldn’t be modified to add new functionality, instead one has to extend the same to add new functionality. In otherwords you don’t touch the existing modules thereby not disturbing the existing functionality, instead you extend the modules to implement the new requirement. So your code is less rigid and fragile and also extensible. (See Reference)

Lets look at the code below which draws triangle and rectangle:

public class OCPViolation {
	class Drawer{
		public void drawRectangle(Rectangle shape){
			System.out.println("Rectangle is drawn");
		}
		
		public void drawTriangle(Triangle shape){
			System.out.println("Triangle is drawn");
		}
	}

	class Rectangle{}
	
	class Triangle{}
	
	public static void main(String[] args) {
		OCPViolation test = new OCPViolation();
		
		Drawer drawer = test.new Drawer();
		Rectangle rect = test.new Rectangle();
		Triangle tri = test.new Triangle();
		
		drawer.drawRectangle(rect);
		drawer.drawTriangle(tri);
	}
}

Code above violates OCP principle, because if a new shape is required to be drawn, it needs change in Drawer so refactor code as below to be OCP compatible:

public class OCPCompatible {
	class Drawer {
		public void draw(Shape shape) {
			shape.draw();
		}
	}

	interface Shape {
		public void draw();
	}

	class Rectangle implements Shape {
		public void draw() {
			System.out.println("Rectangle is drawn");
		}
	}

	class Triangle implements Shape {
		public void draw() {
			System.out.println("Triangle is drawn");
		}
	}

	public static void main(String[] args) {
		OCPCompatible test = new OCPCompatible();

		Drawer drawer = test.new Drawer();
		Rectangle rect = test.new Rectangle();
		Triangle tri = test.new Triangle();

		drawer.draw(rect);
		drawer.draw(tri);
	}
}

....

Single-Responsibility Principle (SRP)

This principle is S of S.O.L.I.D design principles.

According to Single Responsibility Principle, Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.

The SRP is one of the simplest of the principle , and one of the hardest to get right.

A detailed description with an example can be found here

Liskov Substitution Principle (LSP)

This principle is L of S.O.L.I.D design principles.

According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue”. LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality and does violated LSP. In order to follow LSP design principle, derived class or sub class must enhance functionality not reducing it. (See Reference)

How can we identify LSP violation?

Derived class may require less functionalities than the Base class, so some methods would be redundant. We might be using IS-A to check for Super-Sub relationships, but LSP doesn’t use only IS-A, but it also requires that the Sub types must be substitutable for the Super class. And one cannot decide the substitutability of sub class in isolation. One has to consider how the clients of the class hierarchy are going to use it. (See Reference)

Lets take look at the code below which violates LSP by binding swim and fly functionality to Base class Bird and use this functionalities by sub classes.

import java.util.ArrayList;  
 import java.util.List;  
 /*  
  * This class demonstrates Liskov Substitution Principle  
  */  
 public class LSPViolation {  
      abstract class Bird{  
           public abstract String getName();  
           public void sound(){  
                System.out.println(getName() + " sounds");  
           }  
           public void fly(){  
                System.out.println(getName() + " flies");  
           }  
           public void swim(){  
                System.out.println(getName() + " swims");  
           }  
      }  
      class Canary extends Bird{  
           public void swim(){  
                throw new UnsupportedOperationException(

                                          "Canary can not swim");  
           }  
           public String getName() {  
                return "canary";  
           }  
      }  
      class Penguin extends Bird{  
           public String getName() {  
                return "penguin";  
           }  
           public void fly(){  
                throw new UnsupportedOperationException(

                                          "penguin can not fly");  
           }  
      }  
      public static void main(String[] args) {  
           LSPViolation lspViolation = new LSPViolation();  
           List<Bird> birds = new ArrayList<Bird>();  
           birds.add(lspViolation.new Penguin());  
           birds.add(lspViolation.new Canary());  
           for (Bird bird : birds){  
                bird.sound();  
                bird.swim();  
                bird.fly();  
           }  
      }  
 }

When we run above code, boom!

 penguin sounds  
 penguin swims  
 Exception in thread "main" java.lang.UnsupportedOperationException: penguin can not fly  
   at LSPViolation$Penguin.fly(LSPViolation.java:40)  
   at LSPViolation.main(LSPViolation.java:54)

So lets fix it by seperating responsibilities as SwimmableBird and FlyableBird:

 /*  
  * This class demonstrates Liskov Substitution Principle  
  */  
 public class LSPCompatible {  
      abstract class Bird{  
           public abstract String getName();  
           public void sound(){  
                System.out.println(getName() + " sounds");  
           }  
      }  
      abstract class FlyableBird extends Bird{  
           public void fly(){  
                System.out.println(getName() + " flies");  
           }  
      }  
      abstract class SwimmableBird extends Bird{  
           public void swim(){  
                System.out.println(getName() + " swims");  
           }  
      }  
      class Canary extends FlyableBird{  
           public String getName() {  
                return "canary";  
           }  
      }  
      class Penguin extends Bird{  
           public String getName() {  
                return "penguin";  
           }  
      }  
 }

Ferhat KUL

Asdfasf

Saturday, February 16, 2013

Interface Segregation principle (ISP)

Open Closed Principle (OCP)

Single-Responsibility Principle (SRP)

Liskov Substitution Principle (LSP)