Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Aspect- vs. Object-Oriented Programming: Which Technique, When?

Aspect-oriented programming claims to address problems that traditional object-oriented programming doesn't completely or directly solve. Find out how true that claim is with a line-by-line comparison of the two techniques.


advertisement
ike most developers, I have been developing software systems using object-oriented programming (OOP) techniques for many years. So when I read that aspect-oriented programming (AOP) addresses many problems that traditional OOP doesn't solve completely or directly, I wanted to better understand its benefits in real world application development. I thought comparing both techniques would provide some practical insight. So I decided to design a case study: an OOP application in which I identified aspects where AOP might be a good fit.

This article presents a similar case study. It begins by introducing a problem domain and then demonstrates two solutions: one that uses OOP and one using AOP. The AOP solution uses a JDK 1.5, JUnit, and AspectWerkz implementation. (The complete source code for both approaches is available in the "Download the Code" section in the left-hand column.) Finally, it demonstrates how to code a few aspects.

By the end, you will know all you need to know about using AOP in the real world, including what it tries to solve in software design.



 
Figure 1. Domain Model for the Solution

Problem Domain Description

A software company employs a programmer, assigns him to a business unit, and has him report to a manager. The manager gives his team members credit points when they meet their objectives. The company's required solution must add a new employee and give credit points to existing employees. To keep things simple, the persistence can be done in a CSV file.

Figure 1 illustrates the domain model for the solution to this problem.

The Manager class is derived from the Employee class, and it contains an additional attribute, Managing Project. A set of employees would be part of a business unit. The business units form the company. Ignore the Company class, since it is out of this problem domain's scope.

 
Figure 2. Sequence Diagram of Object Interactions

The Solution Application's Design

The design for the solution can best be explained with a sequence diagram. Figure 2 represents the interaction between the objects for a solution that adds a new employee to the organization and assigns him or her to a business unit and a manager. This article explores only the required details of the application to keep things simple. However, you can explore the code directly for additional information.

EmployeeServiceTestCase, a JUnit test case class, simulates an end user, creates a new employee record, and assigns him to a business unit and manager. It fetches all the available business units and managers to populate the GUI. The repository classes load data from storage. To instantiate the domain objects BusinessUnit and Manager, the retrieved record is passed to the factory classes. Later, an Employee object is created by passing these references to the EmployeeService object. The service class uses EmployeeFactory to create the object and passes it to EmployeeRepository for persisting in storage.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap