WHAT IS WRONG WITH AOP? Adam Przybylek Department of Business Informatics, University of Gdansk, Piaskowa 9, 81-824 Sopot, Poland adam@univ.gda.pl Keywords: aspect-oriented programming, AOP, separation of concerns, modular programming. Abstract: Modularity is a key concept that programmers wield in their struggle against the complexity of software systems. The implementation of crosscutting concerns in a traditional programming language (e.g. C, C#, Java) results in software that is difficult to maintain and reuse. Although modules have taken many forms over the years from functions and procedures to classes, no form has been capable of expressing a crosscutting concern in a modular way. The latest decomposition unit to overcome this problem is an aspect promoted by aspect-oriented programming (AOP). The aim of this paper is to review AOP within the context of software modularity. 1 INTRODUCTION The history of programming languages may be seen as a perennial quest for better separation of concerns (SoC). The term SoC was coined by Dijkstra (1974) and it means “focusing one's attention upon some aspect” to study it in isolation for the sake of its own consistency; it does not mean completely ignoring the other ones, but temporarily forgetting them to the extent that they are irrelevant for the current topic. In the context of systems development, this term refers to the ability to decompose and organize systems into manageable modules, which have as little knowledge about the other modules of the system as possible. Programming languages provide mechanisms that allow the programmer to define modules, and then compose those modules in different ways to produce the overall system. However, Kiczales et al. found that sometimes some issues of the problem cannot be represented as first-class entities in the adopted language. The reason why such issues are hard to capture is that they cut across the system’s basic functionality, so their implementation will be spread throughout other modules (Kiczales et al. 1997). Such issues are called crosscutting concerns. The symptoms of implementing crosscutting concerns in a procedural or object-oriented (OO) language are “code scattering” and “code tangling”. Code tangling occurs when implementations of different concerns coexist within the same module. Code scattering occurs when the similar code fragments, responsible for the same concern, spread through many modules. Code tangling and scattering are damaging to the software architecture. Efforts to deal with the phenomena of code tangling and scattering have resulted in aspect- oriented programming (AOP). Although AOP introduces a new unit of modularity to implement crosscutting concerns, it comes with its own set of problems. The distinguishing characteristic of AO languages is that they provide quantification and obliviousness (Filman & Friedman 2001). Quantification is the idea that one can write an aspect that can affect arbitrarily many non-local places in a program (Steimann 2006). Obliviousness states that one cannot know whether the aspect code will execute by examining the body of the base code (Filman 2001). Quantification and obliviousness cause problems such as difficulties in reasoning or maintenance (Leavens & Clifton 2007). Hence, AOP, by preventing code tangling and scattering, improves code quality in one area, and at the same time, by introducing quantification and