Designing Abstract Classes and Interfaces in J2EE Applications

Advanced Design Concept - Abstract classes and Interfaces

Using abstract classes and interfaces are the very important design decisions to be made by the technical leads and application architects to make the application very effective. It not only makes the effective application design and it also helps the team to effectively develop codes during the design and coding phase.

When to use Abstract Classes? When to use Interface? What is the practical use?

Basically everyone knows the theory behind it. If you do not want to make the instance directly, you will use abstract classes. To define the structure of the classes you use interface.

But thats ok. What is the practice? In the interview, the questions are normally asked as 'Give the scenario where you use abstract classes and interface' or 'Why do we need abstract classes if you cannot create the instance?'.

Let us discuss it. Take the scenario of a typical J2EE logging-in module. The concept of logging in would effect only when the user exists. If the user exists and the password is right, you will allow the user to go ahead further. But the user is of different kind. He may be the simple user or administrator. So this is decided by authorization, where the user is listed out the pages or components which he can access. How do we do it? This magic is achieved by abstract class. Let us assume the following classes:

The abstract class is named as 'UserAuthorization'.
The normal class is named as 'UserDetails'.
The interface is User.

You cannot authenticate differently for different people. Authorization mechanism is one for each application. So we can design as follows:

Class UserDetails extends UserAuthorization implements User
{
.......
}

The above prototype explains the concept. The UserDetails contains the name, type, address and phone numbers. The UserAuthorization class uses these values supplied through parameters and performs the authorization. Since it is a super class, the UserDetails class can directly access those data and get the authorization details. The interface enforces the UserAuthorization and UserDetails classes to compulsority declare the necessary methods.

In this example, the abstract class has no need to get instantiated and used only by the derived classes. The need of interface is a beautiful concept. Once the architect designs the prototype of the methods, all the team members, wherever they are, must necessarily use exactly the same prototype to avoid errors. Obviously, they would have no rights to change the signature of the methods found in interface. They only have to adjust their classes to suit the needs of the application decided by the architect. This is how the common components are designed to minimize the application bugs and to enfore the common design principles and consistency.

Hope this explains the Abstract classes and Interface. If you feel this useful, write to me to swathikalakshmi@gmail.com.

I would come out with yet another beautiful concept in my blog. Keep visiting.

Thanks & Regards,
Swathika.