AOP aims at reducing the amount of "tangled" code by which we mean code that might be implemented in different classes if a OOP language is used but still share important secondary requirements. Such requirements are said to cross-cut the system's basic functionality and are difficult to develop and maintain using non-AOP programming paradigms. Cross-cutting functionality can be thought of as functionalty spanning many objects.

Logging is the prototypical example of a cross-cutting concern. E.g. an application might use logging in multiple classes when methods are entered or exited. So even though the classes themselves have different responsibilities and are implemented differently they still perform the same secondary functionality, in this case, logging.

To sum up: The goal of AOP is to support the programmer in cleanly separating compontents and the cross-cutting concerns of these, in AOP-lingo called aspects, from each other. This is achieved by promoting the cross-cutting concerns to first-class program modules.

The goal of AOP is in contrast with OOP and POP in that those paradigms only separate components from each other. 

Aspects and componets - two important terms

An aspect - something which cannot be cleanly encapsulated in a generalized procedure (e.g. the functionality of a class in a OOP language). This means that an aspect is cross-cutting concern as defined in the paragraph above. An example of an aspect is the synchronization of concurrent objects. Many performance-related issues are aspects.

A component - something that can be cleanly encapsulated in a generalized procedure. E.g. a GUI. A component can also be defined as something not sharing secondary requirements with other components.

How AOP works

In the general case, an AOP-based implementation of an application relies on a component language, an aspect language and an aspect weaver. The application consists of programs implementing the components, programs implementing the aspects and the weaving of the two types of programs.

Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns such as transaction management that cut across multiple types and objects. (Such concerns are often termed crosscutting concerns in AOP literature.)

One of the key components of Spring is the AOP framework. While the Spring IoC container does not depend on AOP, meaning you do not need to use AOP if you don’t want to, AOP complements Spring IoC to provide a very capable middleware solution.

Aspect-Oriented Programming (AOP) complements OOP (Object Oriented Programming) by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. AOP allows you to dynamically modify your static model consisting mainly of business logic to include the code required to fulfill the secondary requirements or in AOP terminology called cross-cutting concerns (i.e. secondary requirements) like auditing, logging, security, exception handling etc. without having to modify the original static model (in fact, we don't even need to have the original code). Better still, we can often keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OOP on its own.

Inversion of control or dependency injection (which is a specific type of IoC) is a term used to resolve object dependencies by injecting an instantiated object to satisfy dependency as opposed to explicitly requesting an object. So objects will not be explicitly requested but objects are provided as needed with the help of an Inversion Of Controller container (e.g. Spring, Hivemind etc). This is analogous to the Hollywood principal where the servicing objects say to the requesting client code (i.e. the caller) “don’t call us, we’ll call you”. Hence it is called inversion of control.