The object-oriented paradigm provided the concepts and the right instruments for the creation of complex programs and had a great impact on the development of new disciplines in the domain of software design. In this sense, both engineering and software design disciplines developed greatly. Particularly important has been the development of the so-called Design Patterns that allow a certain degree of systemization of the activity of software design and development.

The concept of a class that includes data and functions that change its values allows for the realization of cohesive and independent entities (high cohesion, low coupling). This in turn realizes the required business functionalities through the exchange of messages.

Using design patterns and object-oriented programming, the development of an application can be realized by dividing the activities into independent groups of functionalities. In fact, as soon as the interfaces of every entity of the application have been defined, their implementation can be realized independently by different groups of developers.

Another advantage is the reliability offered by the object. If we consider that the access to an object's data and its modification can happen only by means of the methods that it exposes through its interface, no user can unpredictably corrupt this data and make that object's state inconsistent.

Finally, the concept of inheritance allows the definition of new classes that extend the functionality of the classes from which they derive. In this sense, we obtain the extendibility and the reuse of software.

After the advantages of the new instruments given by the object-oriented programming paradigm, we have to consider the limits that occurred in practical application.

The main problem is to manage to control the complexity. To face it, we will have to choose modularization: "divide et impera", according to the Latin maxim.

If architects look at the previous projects on which they have worked, they will notice that a common feature is the constant increase in the systems' complexity.

Separating the functionalities that have to be implemented into simpler and more manageable modules helps to control the complexity. Software systems are conceptually complex by their very nature, and increasing their complexity in the implementation means increasing the expense and the probability of its failure.

The code needed to integrate a complex implementation is expensive. The cost would be even higher if new features are required. In fact, those features imply deep changes in several parts of the implementation.

If we didn't take the way of modularization and simplification, we would have a monolithic system that would be unmanageable to modify.

First of all, we have to single out the modules that will implement the core business that justifies the design and the implementation of the software. Once we have completely understood how to implement the core business, we can think about designing the rest of the application so that the core business supports the system's users.

We are used to take the best practice of dividing the application into logical layers (presentation layer, business layer, and data layer). But, there are some functionalities that cross these layers transversally. They are named crosscutting concerns.

A crosscutting concern is, therefore, an independent entity that transversally crosses other functionalities of software. Take a look at the following figure:

The most common crosscutting concerns are: security, logging, transactions management, caching, performance checking, concurrency control, and exception management.

These crosscutting concerns, if implemented only with object-oriented programming, realize a bad matching between the core business and the modules that implement its functionalities. We are forced to deal with the implementation of these transversal functionalities into various modules, moreover, adding other transversal modules or modifying the existing ones. We are also forced to modify the code in which these modules are used. This is owing to the undesired, but necessary, matching that the object-oriented implementation unavoidably brings with it.

The followings graphs (extracts from http://www.parc.com/research/projects/aspectj/downloads/SDWest2002-BetterJavaWithAJ.ppt), show the code of Servlet Engine Tomcat 4 divided in modules:

In the figure above, XML parsing fits in one module.

In the figure above, the URL pattern matching fits in two modules.

In the figure above, logging is scattered in too many modules.

This figure shows the points where Tomcat classes' logging functionalities are called (underlined in red). As we can see, they are scattered in the points of the modules where the functionality is required.

The problem of scattering code derived from the crosscutting concerns in object-oriented programming arises due to its transversality to the crosscutting concerns, which is implemented in the classes. More correctly, the crosscutting concerns should be analysed as a third dimension of the design. Whereas in the implementation there are two dimensions, as shown in the following figure:

In these situations, aspect-oriented programming provides support to object-oriented programming for uncoupling modules that implement crosscutting concerns.

Its purpose is the separation of concerns.

In object-oriented programming the basic unit is the Class, whereas in aspect-oriented programming it's the Aspect.

The aspect contains the implementation of a crosscutting concern, which in the class should coexist with the objects that collaborate with it, for each class that needs it.

In this way, we can write the object-oriented classes without involving the crosscutting concerns in the implementation.

So, classes can freely evolve without taking into account this dependency.

The functionalities provided by the crosscutting concerns in the aspects will be applied to the objects through an aspect weaver or through some proxy classes. We will deal with this in the later chapters.

Now we will see how the problems we exposed, arise in the code.

public interface Info {
public String getName();
public Date getCreationDate();
}
public class ScatteringA implements Info{
public ScatteringA(String name, String author){
creation = new Date();
this.name = name;
this.autor = author;
}
public ScatteringA(Date creation, String name, String author){
this.creation = creation;
this.name = name;
this.autor = author;
}
public Date getCreationDate() {
return (Date)creation.clone();
}
public String getName() {
return name;
}
public String getAutor() {
return autor;
}
private Date creation;
private String name;
private String autor;
}
public class ScatteringB implements Info{
public ScatteringB(String name, String address){
creation = new Date();
this.name = name;
this.address = address;
}
public ScatteringB(Date creation, String name, String address){
this.creation = creation;
this.name = name;
this.address = address;
code scattering, object-oriented programmingcode duplication}
public Date getCreationDate() {
return (Date)creation.clone();
}
public String getName() {
return name;
}
public String getAddress() {
return address;
}
private Date creation;
private String name;
private String address;
}

public class TanglingListUserController extends MultiActionController{
public ModelAndView list(HttpServletRequest req,
HttpServletResponse res) throws Exception {
//logging
log(req);
// authorization
if(req.isUserInRole("admin")){
String username = req.getRemoteUser();
List users ;
//exception handling
try {
//cache with authorization
users = cache.get(Integer.valueOf( conf.getValue("numberOfUsers")), username);
} catch (Exception e) {
users = usersManager.getUsers();
}
return new ModelAndView("usersTemplate", "users", users);
}else{
return new ModelAndView("notAllowed");
}
}
private void log(HttpServletRequest req) {
StringBuilder sb = new StringBuilder("remoteAddress:");
sb.append(req.getRemoteAddr());
sb.append("username:");
sb.append(req.getRemoteUser());
log.fine(sb.toString());
}
…
}