Tutorials : The Mysteries of Business Object - Part 2 :

Mysteries of Business Object-Part 2

Last month, we discussed the nature of Business Objects, including different issues related to Business Objects such as Persistence, Validation and accessing Business Objects. We provided a rough guideline of how Business Objects can be developed as heavy-weight EJB-like technologies or light-weight POJO technologies. This month, we will work with an example application and see how we can come up with Business Objects and different strategies related to the same.

The Problem Domain

Let us consider a sample online phone-card management application. In this application, any customer can pre-pay some money to their individual accounts and then start calling to different destinations. Once their account is out of money, they can again top-off their account and continue making calls. Without elaborating the problem any further, we want to provide the customer a web-interface to look at their call history and their top-off details. Also, we want to allow the customers to change their personal details, pay money to their existing account and also top-off their accounts online. The question is how we would design such applications.

Identifying The Business Objects

In all the applications, it is important first to identify the Business Objects. Business Objects are something that the application User tangibly accesses and modifies. Identifying Business Objects is a complex topic and we have no space in this article to cover that. However, typically nouns in the problem specification serve as a good indicator. In our application scenario, Customer is a potential Business Object. By analyzing further the problem domain, we can list the following Business Objects:

Customer

Address

CallRecord

TopupRecord

We shall again find that all these Business Objects might have associations between themselves. For example, Customer may have an association with Address and CallRecord Business Objects. In the light of these associations, one might decide to create a single Business Object as Customer and have all the associated details as attributes to the Customer Business Object. Though, it will serve the purpose, but it greatly reduces the modularity and reusability of the Business Objects. For example, the following Customer class is specific to the problem domain we are using and cannot be reused in any other application:

public class Customer {
  
  private String address1;
  private String address2;
  private String[] callDestination;
  private String[] topupDetails;
}

One of the goals of OO Design is to model the application problem domain in terms of associations between objects and achieve the functionality by passing messages between objects. Keeping this in mind, the following customer class is more reusable than the one listed previously:

public class Customer
{
  
   private Address address;
   private CallRecord callRecord;
   private TopupRecord topupRecord;
 
}

A careful reader will question the real difference between these two implementations. In the second example, we have merely hidden the implementation details into another set of classes. While that is true, what we have gained by doing so is that each Business Object now can operate independently of the containing Customer class and implement their own persistence and validation strategies. This provides great flexibility as Address now can be associated not only with Customer but also the Provider should there be a concept of a service Provider in our system.

In our example, Customer is the parent Business Object and Address, CallRecord and TopupRecord are the dependent Business Objects. For the time being, let us forget about the concrete implementation view details and concentrate on modelling and designing the application in the right way. Once we have identified the potential Business Objects within the application domain, we can model their relationship in the following way:

Home / Tutorials / The Mysteries of Business Object / 1 / 2 / 3 / 4

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

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.