|
Here is the code for the SpecialCurrentAccount.
/*
* SpecialCurrentAccount.java
*
*/
package sam.oo.bad;
public class SpecialCurrentAccount extends CurrentAccount{
/** Holds value of property defaultPeriod. */
private int defaultPeriod;
/** Creates a new instance of SavingsAccount */
public SpecialCurrentAccount(int balance, int period) {
super(balance, period);
}
public boolean closeAccount()
{
if(balance>0 && period>defaultPeriod)
return true;
else
return false;
}
/** Getter for property defaultPeriod.
* @return Value of property defaultPeriod.
*/
public int getDefaultPeriod() {
return this.defaultPeriod;
}
/** Setter for property defaultPeriod.
* @param defaultPeriod New value of property defaultPeriod.
*/
public void setDefaultPeriod(int defaultPeriod) {
this.defaultPeriod = defaultPeriod;
}
}
Listing 2 SpecialCurrentAccount.java
Also I decided to offer an interface through another class to operate
on these account objects, which looked like:
public void closeAnAccount(CurrentAccount ac)
{
System.out.println("Account close result: "+ac.closeAccount());
}
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
AccountTest test = new AccountTest();
CurrentAccount ac = new CurrentAccount(100,2);
SpecialCurrentAccount sac = new SpecialCurrentAccount(200,5);
test.closeAnAccount(ac);
test.closeAnAccount(sac);
}
Everything went fine, and I was happy, until a user of this module
discovered an unexpected behaviour with the system. When he tried to do the
above, the result was contrary to his expectation.
Account close result: true
Account close result: false
The closing of a SpecialCurrentAccount object failed and the user has
no clue why, without looking into the source code of the SpecialCurrentAccount
class. But looking into interface closeAnAccount(CurrrentAccount), he is
justified to make an assumption that any type of CurrentAccount object will
behave in a similar manner. But in reality it did not. That made me think a
while and I came to the following conclusions:
- While designing the class hierarchy I have violated the LSP.
- My overridden method closeAccount() in the derived class
SpecialCurrentAccount had broken the module by not allowing a base class
CurrentAccount object to be replaced by derived class object
SpecialCurrentAcount.
- By creating the above hierarchy I had expected the user to know about the
internal implementation of both the account classes before he can be assured of
a guaranteed behaviour of the module. Clearly, this is not desirable and often
he might not have access to the source code to do so.
Design by Contract
The above discussion leads us to the discussion of
the Design by Contract principle. In Design by Contract, each method in a class
can have a pre-condition and a post-condition attached to it. The pre-condition
defines the criteria to be met before the method offers a certain behaviour and
the post-condition is the state or behaviour offered by the method once the
pre-conditions are met. Following that, if we note down the pre-conditions and
post-conditions followed by the CurrentAccount and the SpecialCurrentAccount
classes, they will look like the following:
CurrentAccount.java
/**
* pre condition: the balance >0
* post-condition: the account is closed
**/
public boolean closeAccount()
SpecialCurrentAccount.java
/**
* pre condition: the balance >0
* the period > default period
* post condition: the account is closed
**/
public boolean closeAccount();
The pre-condition set in the sub-type SpecialCurrentAccount contains
more conditions than the base-type CurrentAccount. This is against the Design by
Contract principle. According to the Design by Contract:
A sub-type can
only have weaker pre-conditions and stronger post-conditions than its base
class.
Clearly, my previous design violated the Design by Contract
principle.Having these facts in mind, I had a clear idea what was going wrong and
approached a better LSP and Design by Contract compliant solution.
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.
| 
