Depuis 1997, la programmation orientée aspect (POA) provoque l'engouement de la communauté scientifique s'intéressant au génie logiciel. Cette technique offre de nouvelles perspectives à un principe bien connu en génie logiciel: la séparation des préoccupations (concern).

L'étude des techniques de développement classiques comme les méthodes itératives font apparaître que le principal problème de l'informatique est un problème organisationnel lié à un entrelacement des sous-problèmes techniques ou fonctionnels d'une application.
En effet, si on dispose d'un certain nombre d'outils pour construire des applications à base de composants (BEANS, CORBA, CCM, DCOM…), on ne dispose pas de moyen de les intégrer de façon simple.
Au final, l'ensemble des fonctionnalités et des caractéristiques techniques désirées s'entrelacent et se chevauchent pour former l'effet voulu. Cet enchevêtrement rend l'application difficile à maîtriser, surtout dans le cas des applications réparties, où le nombre de sous-problèmes à traiter est élevé.

Depuis quelques années, l'intérêt de la communauté scientifique pour ce problème s'est accru de manière considérable et de nombreuses tendances et techniques visant à le résoudre ont vu le jour. Parmi les principales, on peut citer la Programmation Orientée Aspect ("AOP, Aspect-Oriented Programming") de l'équipe de G. Kiczales au Xerox PARC en Californie, la Programmation Orientée Sujet (" Subject-Oriented Programming") d'IBM et la Programmation par Intention ("Intentional Programming") de Microsoft.

Toutes ces approches visent peu ou prou à appliquer aux langages de programmation le principe bien connu en génie logiciel de séparation des préoccupations ("separation of concerns"). Plutôt que d'attaquer le développement d'une application de front, ces approches suggèrent de concevoir des composants logiciels indépendants et fournissent des moyens pour les assembler.
Même si les approches sont complémentaires, les techniques de développement par aspects ne doivent pas être confondues avec les techniques d'assemblage par composants. En effet, les techniques de développement par composants se focalisent sur les règles de composition d'un composant particulier par rapport aux autres, alors que les techniques de développement par aspects se focalisent sur la composition d'un ensemble de composants particuliers et correspondant à une préoccupation (comme la sécurité) par rapport à un autre ensemble de composants (le reste de l'application).
En d'autres termes, la POA se focalise sur l'intégration de composants.

La POA diffère grandement de la POO dans la manière dont elle gère les problèmes de recoupements.
Avec la POA, chaque unité implémentée (Aspect) reste inconsciente du fait que les autres unités peuvent l’instancier en tant qu’aspect.
Par exemple, un module de gestion de carte bancaire ne sait pas que d'autres unités journalisent et authentifient ses opérations.
Cela représente un très fort changement de concept par rapport à la POO.

Une implémentation POA peut employer une autre méthodologie de programmation en tant que méthodologie de base, ce qui permet de cumuler les bénéfices des deux approches. Par exemple, une implémentation POA peut choisir la POO comme système de base pour profiter des bénéfices d’une meilleure implémentation des besoins communs au travers de la POO. Avec une telle implémentation, les besoins individuels peuvent employer les techniques de POO pour chaque besoin identifié. C’est analogue au fait d’utiliser un langage procédural comme base pour un langage orienté objet (C et C++ par exemple).

Finalement, on peut voir la POA comme une alternative, plus poussée, à l'utilisation de design paterns, ou autres "astuces", en POO.