Yesterday, I decided to re-write with lambdas one of the example I use while explaining polymorphism during my Java trainings. I realize that lambdas promote functional style of programming and implementing inheritance via composition over polymorphism, which is one of the crucial object-oriented features. Still, I decided to try mixing traditional OOP and functional styles to see what happens.

The Task

The class Person has two descendants: Employee and Contractor. Also, there is an interface Payable that’s used to increase pay for workers.

public interface Payable {
   int INCREASE_CAP = 20;
   boolean increasePay(int percent);
}

Both Employee and Contract implement Payable, but the implementation of the increasePay() should be different. you can increase pay to the Employee by any percent, but the Contractor’s pay increase should stay under INCREASE_CAP.

The OOP version

Here’s the class Person:

public class Person {
	private String name;
	
	public Person(String name){
		this.name=name;
	}

	public String getName(){
		return "Person's name is " + name; 
	}
}

Here’s the Employee:

public class Employee extends Person  implements Payable{

   public Employee(String name){
     super(name);
    }
    public boolean increasePay(int percent) {
    System.out.println("Increasing salary by " + percent + "%. "+ getName()); 
    return true;
  }
}

Here’s the Contractor:

 public class Contractor extends Person implements Payable {
	
   public Contractor(String name){
 	super(name);
    }
   public boolean increasePay(int percent) {
	if(percent < Payable.INCREASE_CAP){
	  System.out.println("Increasing hourly rate by " + percent + 
                                      "%. "+ getName()); 
	  return true;
	} else {
	   System.out.println("Sorry, can't increase hourly rate by more than " + 
                       Payable.INCREASE_CAP + "%. "+ getName());
	   return false;
	}
  }
}

Here’s the code that will perform pay increase in a polymorphic way:

public class TestPayInceasePoly {

  public static void main(String[] args) {

     Payable workers[] = new Payable[3];
	workers[0] = new Employee("John");
	workers[1] = new Contractor("Mary");
	workers[2] = new Employee("Steve");		
	
        for (Payable p: workers){
	    p.increasePay(30);
	 }
  }
}

The output of this program looks like this:

Increasing salary by 30%. Person’s name is John
Sorry, can’t increase hourly rate by more than 20%. Person’s name is Mary
Increasing salary by 30%. Person’s name is Steve

Introducing Lambdas

Now I decided to experiment with lambdas. Namely, I wanted to pass a function as an argument to a method. I wanted to extract the increase pay logic from Employee and Contractor into lambda expressions and pass them to workers as argument to their methods.

I left the code of the Payable interface without any changes.

Here’s the new Person class that includes the method validatePayIncrease, which will take a lambda expression as a first argument (passing a function to a method):

public class Person {
	
	private String name;

	public Person (String name){
		this.name = name;
	}
	
	public String getName(){
		return name;
	}
	
	public boolean validatePayIncrease(Payable increaseFunction, int percent) {
			 
         boolean isIncreaseValid= increaseFunction.increasePay(percent); 
         	 
         System.out.println( " Increasing pay for " + name + " is " + 
        	              (isIncreaseValid? "valid.": "not valid."));
		 return isIncreaseValid;
	}
}

The new version of Employee doesn’t implements Payable:

public class Employee extends Person{

  // some other code specific to Employee goes here

  public Employee(String name){
	  super(name);
  } 
}

The new version of Contractor doesn’t implements Payable either:

	  
public class Contractor extends Person{
    

  // some other code specific to Contractor goes here

    public Contractor(String name){
       super(name);
    }
}

Finally, the program that will increase the pay to all workers passing different lambda expressions to employees and contractors.

public class TestPayIncreaseLambda {
	
  public static void main(String[] args) {

        Person workers[] = new Person[3];
		workers[0] = new Employee("John");
		workers[1] = new Contractor("Mary");
		workers[2] = new Employee("Steve");		

	  // Lambda expression for increasing Employee's pay
	   Payable increaseRulesEmployee = (int percent) -> {
				return true;
	   };
	   
		// Lambda expression for increasing Contractor's pay	   
	    Payable increaseRulesContractor = (int percent) -> {
	    	if(percent > Payable.INCREASE_CAP){
	    		System.out.print(" Sorry, can't increase hourly rate by more than " + 
	    	             Payable.INCREASE_CAP + "%. "); 
				return false;
			} else {	
				return true;
			}
	   };	
	   
	   for (Person p: workers){
		   if (p instanceof Employee){
			   // Validate 30% increase for every worker
			   p.validatePayIncrease(increaseRulesEmployee, 30); 
		   } else if (p instanceof Contractor){
			   p.validatePayIncrease(increaseRulesContractor, 30);
		   }
	   }
  }

}

As you see, I’m passing one or the other lambda expression to the method validatePayIncrease. Running this program produces the following output:

Increasing pay for John is valid.
Sorry, can’t increase hourly rate by more than 20%.  Increasing pay for Mary is not valid.
Increasing pay for Steve is valid.

It works, but so far I like my OOP version better than the lambda’s one:

1. In the OOP version I’ve enforced a contract – both Employee and Contractor must implement Payable. In the lambda’s version it’s gone on the class level. On the plus side, the strong typing still exists in the lambda’s version –  the type of the valiastePayIncrease first argument is Payable.

2. In the OOP version I didn’t use type checking, but in the lambda’s version this ugly instanceof creeped in.

While it’s cool that I can pass the function to the object and execute it there, the price seems to be high. Let’s see if this code can be further improved.

Getting rid of the class hierarchy

Currently the code in Employee and Contractor is the same. If the only difference in their code is implementation of the validatePayIncrease method, we can remove the inheritance hierarchy and just add the property boolean workerStatus to the class Person to distinguish employees from contractors.

Let’s get rid of the classes Employee and Contractor and modify the Person. I’ll add the second argument to the constructor workerStatus.

public class Person {
	
	private String name;
	private char workerStatus;  // 'E' or 'C'

	public Person (String name, char workerStatus){
		this.name = name;
		this.workerStatus=workerStatus;
	}
	
	public String getName(){
		return name;
	}
	
	public char getWorkerStatus(){
		return workerStatus;
	}
	
	public boolean validatePayIncrease(Payable increaseFunction, int percent) {
			 
         boolean isIncreaseValid= increaseFunction.increasePay(percent); 
         	 
         System.out.println( " Increasing pay for " + name + " is " + 
        	              (isIncreaseValid? "valid.": "not valid."));
		 return isIncreaseValid;
	}
}

The code of the TestPayIncreaseLambda will become simpler now. We don’t need to store objects of different types in the array workers and can get rid of the instanceof:

public class TestPayIncreaseLambda {
	
  public static void main(String[] args) {

        Person workers[] = new Person[3];
		workers[0] = new Person("John", 'E');
		workers[1] = new Person("Mary", 'C');
		workers[2] = new Person("Steve", 'E');		

	  // Lambda expression for increasing Employee's pay
	   Payable increaseRulesEmployee = (int percent) -> {
				return true;
	   };
	   
		// Lambda expression for increasing Contractor's pay	   
	    Payable increaseRulesContractor = (int percent) -> {
	    	if(percent > Payable.INCREASE_CAP){
	    		System.out.print(" Sorry, can't increase hourly rate by more than " + 
	    	             Payable.INCREASE_CAP + "%. "); 
				return false;
			} else {	
				return true;
			}
	   };	
	   
	   for (Person p: workers){
		   if ('E'==p.getWorkerStatus()){
			   // Validate 30% increase for every worker
			   p.validatePayIncrease(increaseRulesEmployee, 30); 
		   } else if ('C'==p.getWorkerStatus()){
			   p.validatePayIncrease(increaseRulesContractor, 30);
		   }
	   }
  }
}

If a new type of a worker will be introduced (e.g. foreign workers), we’ll just need to add another lambda expression to the class TestPayIncreaseLambda that implements business rules for foreign workers.

The purists may not like the fact that I’m using hardcoded ‘E’ and ‘C’.You can add a couple of final variables EMPLOYEE and CONTRACTOR at the top of this class.

So what’s the verdict? Losing polymorphism may not be a bad thing. The code became simpler, we’ve removed two classes, but didn’t lose the type enforcement (the Payable interface). Software developers that use functional programming languages live without polymorphism and don’t miss it.

P.S. As a matter of fact you can lose the Payable interface too. This would require a different implementation of our lambda expressions with the help of the interfaces from the new package java.util.function. But this should be a topic of a separate blog. OK, here’s a hint: I did it using the BiFunction interface.