Home > Applications > App Development

Computerworld - To understand aspect-oriented programming (AOP), let's first take a look at two models of labor union organization in the U.S. The old American Federation of Labor organized workers vertically, according to their particular craft or trade. Thus, a large company might have dozens or hundreds of unions to deal with, each representing a specific group of workers. The younger Congress of Industrial Organizations, on the other hand, organized a single union for all workers in a given industry regardless of their individual trades.

Under the AFL approach, each separate craft union needed its own officers and organizers, and each would have to negotiate separately with management. The CIO's horizontal approach, however, cut across the different trades; it could provide similar services and benefits for all workers in a company en masse.

Traditional programming methodologies, even structured and object-oriented approaches, are vertical or hierarchical in nature, like the AFL model. For any given application, there are a number of common operations that, because of minor differences in their logic, the way they're handled, the other modules they interact with or the data they use, must be programmed separately. With AOP, the idea is to look at these operations and abstract them in such a way that they can be called from anywhere.

Method Calls

AOP uses a new type of software module, called an aspect, that cuts across traditional classes and organizational models. The essence of AOP is that every object-oriented program, well designed or not, contains some method calls that appear in several places throughout the program.

Method calls transfer control to a specific closed subroutine within a program. If you change the call to a particular method or its error-handling routine, you may need to make changes in every occurrence of this call -- potentially requiring hundreds or thousands of manual edits. Such crosscutting typically occurs in distribution, synchronization, failure handling, policy enforcement and performance optimization, as well as in a number of common design patterns.

Prior to AOP, developers found it difficult to deal with this crosscutting behavior, because separate pieces of identical or nearly identical code were scattered throughout many different modules. AOP lets you program an aspect once and then reuse it. AOP encapsulates behaviors that affect multiple classes into reusable modules. A code weaver (which can be an interpreter, compiler or preprocessor) then combines the aspects and the classes appropriately.

Some developers have been concerned because when you make a change in an aspect, there's generally no simple way to know which modules will be affected by it. But AOP integrated development environment extensions address this problem, making it possible to browse the crosscutting structure of aspects.