AOP / Dependency Injection (DI).

http://static.springframework.org/spring/docs/2.0.x/reference/aop.html
Implement crosscutting concerns using Spring 2.0 AOP Spring 2.0 offers excellent user-friendly AOP capabilities
By Ganesh Ghag, JavaWorld.com, 01/05/07

Most developers will acknowledge how implementing crosscutting concerns such as logging, auditing, security and transactionality can adversely affect business logic implementation. Such concerns "seem" to increase the complexity of existing business logic, at times making it difficult if not impossible to clearly distinguish business logic from the crosscutting concern implementation.

I had been hearing about aspect-oriented programming (AOP) being a solution for implementing crosscutting concerns. But having read through early AOP tools documentation, I was dissuaded from using AOP in my projects' recommendations, primarily because of a concern that average developers might not "get" AOP concepts, and the overall ability to debug applications, and maintain them, might be restricted to those few who understood AOP.

Recently released Spring 2.0 provides excellent, easy-to-use AOP capabilities. Spring AOP is now remarkably easy to use for the average Java developer with traditional object-oriented programming skills. This story shows how Spring 2.0 AOP can be effectively used to implement crosscutting concerns in a typical software project. We will consider the following crosscutting concerns for implementation:

Security
Logging
Transactionality
Let us start with an example code snippet:

Before we begin, let's review a few basic definitions used in aspect-oriented programming and their implementation in Spring AOP.

AOP basics
Aspect: A modularized implementation of a software concern that cuts across various objects in a software implementation. Logging is a good example of an aspect. In Spring AOP, aspects are nothing more than regular Spring beans, which themselves are plain-old Java objects (POJO) registered suitably with the Spring Inversion of Control container. The core advantage in using Spring AOP is its ability to realize the aspect as a plain Java class.
Join point: A point during program execution, such as a method executing or an exception being handled. In Spring AOP, a join point exclusively pertains to method execution only, which could be viewed as a limitation of Spring AOP. However, in reality, it is enough to handle most common cases of implementing crosscutting concerns.
Advice: Information about "when" an aspect is to be executed with respect to the join point. Examples of types of advice are "around," "before," and "after." They specify when the aspect's code will execute with respect to a particular join point.
Pointcut: A declarative condition that identifies the join points for consideration during an execution run. Pointcut is specified as an expression. Spring AOP uses the AspectJ pointcut expression syntax. An example pointcut expression is: execution(* com.myorg.springaop.examples.MyService*.*(..)). Asterisks in the expression refer to wildcards, as is conventional.

The above AOP code can be easily compiled with the Java 5.0 compiler. There is no need for a separate AOP compiler. Spring uses Java 5.0 dynamic proxies to implement Spring AOP. Needless to say, the weaving of Spring AOP aspects into the application code occurs at runtime, because of the use of dynamic proxies.


Logging as an AspectLogging has a lot of characteristics that make it a prime candidate for implementation as an aspect. The following are two of the notable characteristics:
Logging code is often duplicated across an application, leading to a lot of redundant code across multiple components in the application. Even if the logging logic is abstracted to a separate module so that different components have a single method call, that single method call is duplicated in multiple places. - asr: It seems you do not have to call logging in Spring AOP one declaration of what all classes need logging seems takes care

Logging logic does not provide any business functionality; it's not related to the domain of a business application.

________________________________________________________________________________
Learn AspectJ to better understand aspect-oriented programming -- 03/01/02
AspectJ language overview
To support AOP, AspectJ adds to the Java language concepts:

Joinpoints: Points in a program's execution. For example, joinpoints could define calls to specific methods in a class
Pointcuts: Program constructs to designate joinpoints and collect specific context at those points
Advices: Code that runs upon meeting certain conditions. For example, an advice could log a message before executing a joinpoint

Aspect Hello world
Add Japanese manners to HelloWorld
Now that you've seen the around() advice and collecting context, let's use it to add manners, Japanese style, by adding a "-san" suffix to each person's name to show respect. We simply add another aspect: JapaneseMannersAspect. This aspect advises the call to HelloWorld.sayToPerson(String, String) and proceeds with a modified person argument by adding "-san":

// JapaneseMannersAspect.java
public aspect JapaneseMannersAspect {
pointcut callSayMessageToPerson(String person)
: call(* HelloWorld.sayToPerson(String, String))
&& args(*, person);
void around(String person)
: callSayMessageToPerson(person) {
proceed(person + "-san");
}
}



__________________________________________________________________________________
A Beginer guide to Dependency Injection (DI). - dated July 2005


Scope
This article presents a high level overview of Dependency Injection (DI). It aims to present the overall concept of Dependency Injection to the junior developer within the context of how it could be used in a variety of DI containers.

Dependency Injection (DI) or Inversion of Control (IOC) ? A lot of current literature often refers to the same design pattern as either Dependency Injection or Inversion of Control. I prefer Dependency Injection from my belief that it is a more specific name. I can imagine many scenarios where one would find evidence of Inversion of Control, though the resultant pattern is unlikely to be focusing on resolving dependencies (e.g. moving from a console application to a Windows Event Loop) . However should you prefer IOC, you can pretty much read the remainder of the article by replacing DI with IOC. Within IOC there are various types (creatively called as type 1, type 2, type 3). The differences within these types are not particularly relevant to the scope of this article and thus not entered into.

Dependency Injection in a Software Context
Software components (Clients), are often a part of a set of collaborating components which depend upon other components (Services) to successfully complete their intended purpose. In many scenarios, they need to know “which” components to communicate with, “where” to locate them, and “how” to communicate with them. When the way such services can be accessed is changed, such changes can potentially require the source of lot of clients to be changed.