Tutorials : Designing Abstraction :

Designing Abstraction

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.

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 a LoanValidator 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 with PersonalLoanValidator 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 LoanRequestHandler and 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.

Samudra Gupta has six years of Java related application development experience. He has been involved in various research based projects in Java including e-commerece based and application design and development projects. He is based in the United Kingdom. In his freetime, he is a columnist in different Java Magazines and Journals and loves to play contract bridge.

How to Add Java Applets to Your Site

New on the Java Boutique:

New Article:
Struts in Action
The newest book excerpt from "Struts in Action" covers validators, bundles and configuration files.
... [more articles]

New Tutorial:
Converting XML documents to Java objects with Castor XML
If you're working with XML documents, and your focus is more on the contents of the documents, and not so much on the XML structure, then Castor XML may be what you're looking for. This month Keld Hansen focuses on the conversion capabilities of Casto XML.
... [more Tutorials]

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.