Here I will be posting a scenario through which you can understand why and where first two mantras of design patterns fits well:
1) Always code on basic of interface instead of implementation.
2) consider composition over inheritance.
consider a scenario :
suppose there are different employee in your company and they are categorized on the basis of their designation like :
architect, tech lead ----> category A.
senior developer, junior developer -- > category B
sales manager, Hr ------> category c
Now your application needs to display the display the salary of employee of different category .
architect, tech lead ----> category A.
senior developer, junior developer -- > category B
sales manager, Hr ------> category c
Now your application needs to display the display the salary of employee of different category .
solution :
how you will approach for the solution:
1st way : Following the inheritance concept And relying on Implementation class
i have my first class as :CategoryA . java for employee of categoryA
package in.technoscience.first;
public class CategoryA {
double baseSalary;
double overTime;
public CategoryA(double base, double overTime) {
baseSalary = base;
overTime = this.overTime;
}
public double getSalary() {
return (baseSalary + overTime);
}
}
Now my second class : CategoryB . java for employee of CategoryB
package in.technoscience.first;
public class CategoryB {
double salesAmount;
double baseSalary;
final static double commission = 0.02;
public CategoryB(double sa, double base) {
baseSalary = base;
salesAmount = sa;
}
public double getSalary() {
return (baseSalary + (commission * salesAmount));
}
}
Now a class to represent Employee : Employee.java
package in.technoscience.first;
public class Employee {
CategoryA salaryCalculator;
String name;
public Employee(String s, CategoryA c) {
name = s;
salaryCalculator = c;
}
public void display() {
System.out.println("Name=" + name);
System.out.println("salary= " + salaryCalculator.getSalary());
}
}
A class to test our application: MainApp.java
package in.technoscience.first;
public class MainApp {
public static void main(String [] args) {
CategoryA cA = new CategoryA(10000, 200);
Employee emp = new Employee ("technoscience",cA);
emp.display();
}
}
Explanation:
- A client object can use an Employee object with values for the name and the category type attributes at the time of invoking its constructor.
- here our testing class(MainApp.java),Creates an instance of the CategoryA class by passing appropriate details required for the salary calculation.
- Creates an Employee object and uses it with the CategoryA object inside constructor.
- Invokes the display method on the Employee object to display the name and salary for the employee.
- The Employeeobject makes use of the services of the CategoryA object in calculating the salary of the employee it represents. In this aspect, Employee object acts as a client to the CategoryA object
Limitations :
- This design works fine as long as application needs to calculate the salary for
Category-A employee only. - This design also works fine when we have only one class of objects that provides this service.
- Here from the above code Employee object expects the salary calculation service provider object to be always of the CategoryA class type . And this tight coupling will affects the maintainability and results in an application design that will be restrictive in terms of its future enhancement.
- As per above code, suppose application also needs to calculate the salary of employees who are part of Category-B.
- The main application object (testing class) MainApp.java will be able to create an instance of the CategoryB class but will not be able to use the Employee object with CategoryB instance.
- This is because the Employee object expects the salary calculator to be always of the CategoryA type.
- Due to above reason, the main application will not be able to reuse the existing Employee class to represent different category of employees.
- Still if you want to stick with this code then you have make modification in different class at different places and that will introduce maintenance problem.
Solution:
- so to overcome this problem we can adopt the interface based coding and use the different concepts like runtime polymorphism
- Apart from using runtime polymorphism we can use the concept of composition over inheritance.
- Adopting to interface based coding style will make our classes loosly coupled
- And once it is loosely coupled then it can solve the maintenance problem and code will be more adaptable.
I will explain approach to make this code better in my Next Post, Keep visiting.
No comments:
Post a Comment