Designing Abstraction
by Samudra Gupta
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.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
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.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|