Overview

Evolution of software technology has approached it's next stage, aspect-oriented programming (AOP).

The previous paradigm, object-oriented programming (OOP) is a great improvement to structured programing (which in turn is an improvement on the ancient spaghetti code). It implements a new concept, the object, which can be used as a representation of a real-life object or concept. The object can encapsulate the properties of things in a way that was difficult with standard structured tools. The ideas of OOP, encapsulation, inheritence, polymorphism, information hiding etc. have been implemented in several 3rd+ generation languages, and have recieved wide acceptance in the software industry.

Yet, OOP has it's limitations. Object interfaces can supposedly be entirely abstract, in practice, however, tend to be very implementation dependent. As interfaces become influenced by the technology used (e.g. dependent on the database scheme behind the object hierarchy), event and message paths become complicated. Making changes to an object hierarchy at it's top level can be a mind-boggling task, often requiring breaking dependencies in the entire object hierarchy. Moving to a different technology, such as a different user interface system, or an other database backend can be a huge task.

One of the problems goes down to the objects connecting to each other on too many points. Minimizing these interfaces ultimately makes development easier, but the techniques that minimize the interfaces are difficult to implement. The cause of convoluted interfaces, among other things is that objects aren't entirely abstract by nature, they tend to do some other things beside their 'real-life' modeling. These things, called 'aspects', include support for storing and retrieving, user interface interactions, support for distributed processing, and the list goes on.

Should someone with too much free time decide to color the source code of an application program, with the colors representing the various aspects (e.g. black: problem domain, green: database, red: user interface, etc.), he would find a very mixed view, with the different colors mixed all across the program code, and especially the interfaces.

This sheds some light on a solution to our problem: find a way to completely separate the various aspects of the application. Notice how the program's functionality (the problem which the application is to solve, the 'domain') is the only task that has to be done for each application by hand, the other aspects can (and should) be automated, as these require a lot of work and little thought on the programmer's side. Also domain programmers are often specialized to the domain field, and have less knowledge of, say, GUI libraries. It would be great if we could write just the domain model for the application, and have the other parts magically inserted to the appropriate places. This is called aspect oriented programming.

Persist/J aims to weave persistency into the domain. Persistency allows for an object hierarchy to be written to, and later read from background storage, such as document files or databases.