OOD principles

All text copied from various sources :

LiskovSubstitutionPrinciple

This principle is just an extension of the Open Close Principle and it means that we must make sure that new derived classes are extending the base classes without changing their behavior. Its corollary not principle.

Dependency Inversion Principle [DIP]

All said and done, why is it called Dependency Inversion Principle? The answer is again in thought thinking patterns. In the traditional approach, we start thinking from the high-level modules and cascade down to the lower levels. For example, we initially thought, we need an object to write data to the database and then created another object to write the data to the database and strongly coupled the high-level writer object to the low-level database writer object. This led to the bad design.

In Dependency Inversion Principle, we started thinking from the low-level modules. We identified that we may need to write to different destinations and thereby may need many Writer objects in the system. But all of them are writing data to somewhere and abstracted it to the Writer object. Then we associated this abstraction to the high-level module, the DataWriter.

Last month, we discussed Liskov’s Substitution Principle (LSP). In this article, we will discuss the abstraction principle. While LSP describes different considerations to be made while creating sub-types in the application architecture, the abstraction is all about the design flexibility. If you are interested in good Object-Oriented design, this article is for you.

Open Close principle [OCP]

Is it Open or Closed?

This is the first question you should ask yourself after you have finished writing your application module. Beware if the answer is closed. It means you need to take a fresh look at your design. Object Oriented software does not only mean that your application is a combination of several objects but it must satisfy the requirements that the design is flexible, and OPEN for extension. At this point of time, we will define the Open-Closed principle (OCP) formally as:

A software module which should be closed for modification but open for extension.

You may wonder how it is possible to extend an application without modifying it. Precisely, a good OO design gives you this power. Remember, bug fixing your application is not an extension. Think about how Object1 uses Object 2 and Object 2 provides some business logic to Object1. This business logic may be customer specific. To meet different customer needs, if you have to change the business logic embedded in Object 2, your application is violating OCP.

So far so good but the example speaks more than a thousand words and I will present examples to illustrate the points about OCP. If you follow the examples, you should be able to understand and apply OCP in your own application design.

Strong Coupling

What it is? It means that one application module is totally dependent on the implementation of another module. This is the first sign of violation of OCP. Consider this example. You are going to design a banking application where a particular loan request is passed through aLoanValidator to approve the loan request. The LoanValidator looks to see if the balance is above certain values and then approves the request. Given this problem, one guy comes up with the following classes.

The LoanRequestHandler can assess a loan request. This class holds the balance and period of existence for a particular bank account. I have simplified all other features that this class should normally bear to represent a physical bank account. But still this is sufficient to make the point.

Listing 1 LoanRequestHandler.java

public class LoanRequestHandler {   private int balance;  private int period;  /** Creates a new instance of LoanRequestHandler */  public LoanRequestHandler(int balance, int period) {   this.balance = balance;   this.period = period;  }   public void approveLoan(PersonalLoanValidator validator) {   if(validator.isValid(balance))     //sanction the loan     System.out.println("Loan approved...");   else     System.out.println("Sorry not enough balance...");  } } 

This program can tell you if your loan request is approved or not. It uses another object PersonalLoanValidator to decide if the loan request is valid or not. The PersonalLoanValidator just checks to see if the balance is more than 1000 and approves the loan or else rejects it.

Listing 2 PersonalLoanValidator.java

public class PersonalLoanValidator {  /** Creates a new instance of PersonalLoanValidator */  public PersonalLoanValidator() {  }   public boolean isValid(int balance) {   if(balance>1000)    return true;   else    return false;  } } 

Problem

Do you see the problem with the above design? Probably yes. The LoanRequestHandler object is strongly coupled withPersonalLoanValidator object. What happens if the LoanRequestHandler object should be used to verify a business loan. Certainly, your business logic to approve a business loan will be different and PersonalLoanValidator is not capable of handling this business logic.

One solution may to be add another method to the PersonalLoanValidator class to verify the business loan approval process. Also we need to modify the LoanRequestHandler object with an if-else loop to apply different Validator objects for personal loans and business loans. This means every time the bank decides to provide a different type of loan, we need to make change in the LoanRequestHandlerand PersonalLoanValidator objects.

This application is certainly not closed for modification. This is where the OCP comes into the picture. This application has violated the OCP and therefore it is not properly designed.

Single Responsibility principle [SRP]

  assignToSite(emp, site)  // procedural 
   // OOP 
   emp.assignToSite(site)   // OO variation 1 
   Or 
   site.assignEmp(emp)    // OO variation 2 
   Or 
   site.employeeList.add(emp)  // OO variation 3