From everything I have learned about "Aspect-Oriented Programming" or "Aspect-Oriented Software Development," labeling it as a programming paradigm or methodology appears to be inaccurate. From what I can tell it is not a fundamental technique for programming.

To nail down what is meant by "paradigm" and "methodology," please refer to the following definitions from the American Heritage Dictionary. Compare how well or poorly "Object-Oriented Programming" applies to each vs. how well AOP fits.

Paradigm: A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline.

Methodology: A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods.

"Evidence-based medicine" satisfies the definition of paradigm, but "hysterectomy-based medicine" would be a misnomer because the problem space is too narrow.

I am getting the impression that AOP may be misnamed because based on the "oriented-programming" suffix, AOP is alleging to be both a paradigm and a methodology in the same way "Object-Oriented Programming" is.

Both of these terms (paradigm and methodology) indicate a fundamental technique, where what I understand about aspects is a technology for solving a narrow problem scope, maybe comparable in magnitude to the static variable feature of Java.

If it's true that aspects solve a narrow set of problems, and AOP isn't a misnomer, then why shouldn't all programming techniques be given the "oriented-programming" suffix, such as "inheritance-oriented programming," "dependency-oriented programming," or "scope-oriented programming?"


3 Answers 3


I think this is a really iffy issue because the definition of a "methodology" and "paradigm" and "-oriented programming" is potentially a bit loose in this context, but I'm going to play devil's advocate and go with "yes, it's a misnomer".

Even if you didn't use AOP or AOP features to solve a problem, you'd still be thinking about those aspects -- you might have them written as documentation somewhere, or you might use a code generator -- either way, the concept of aspects is still there. That could also go with any paradigm; though it would be quite ugly, you could still do OOP in C.

So wouldn't that mean that AOP is just as much a methodology as OOP is? I think there's more to it than that.

The reason is that a methodology offers solution to a particular kind of problem. You don't use more than one methodology to solve a conceptual problem, even though you might use two or more in the larger scheme. You might use OOP and procedural to write a data entry UI, but you're only using OOP to describe the abstract structure of the UI, and you're only using procedures (more accurately, methods) to describe its behavior. At the core constituents of a problem, methodologies are mutually exclusive -- and AOP can still take part in solving a problem with functional, OOP, or procedural code.

AOP solves problems in the sense that it reduces the amount of repeated code, but that's well within the job description of a language feature. You haven't really solved any actual problem conceptually by saying that you'll get the compiler or runtime to inject some code that you didn't have to explicitly write; you've just made your code a bit more organized. Declaring that "all of my functions will log their start and finish times" isn't a solution to a problem; it's only a problem statement.

I think it would be more appropriate for them to simply be called "Aspects", as a language feature.

  • 2
    AOP definitely isn't the same category of thing as OOP. I think what happened is that someone went "aspects are a language construct; objects are a language construct; if you're using objects you're doing OOP; THEREFORE if you're using aspects you're doing AOP". When really, a construct comparable to an aspect would be an exception, or a function pointer or something, and nobody says "exception-oriented programming". Jun 20, 2011 at 14:51
  • @Tom That's a really convincing way to look at it. Jun 20, 2011 at 19:01

All development methodologies are merely ways of thinking about organization of code. Each development methodology may produce very different looking code, or they may produce similar code. They may also require libraries or language features for support.

In C++ for instance, AOP is typically implemented using traits classes and compile-time polymorphism. It's not a language "feature" at all -- you build the various aspects of your type, and the combine them however you like with templates.

In languages like Java which do not have something like templates, you do end up needing to use dedicated language features provided by preprocessors (e.g. AspectJ) in order to program in an aspect-oriented manner, simply because the original language does not have the capability of implementing true AOP itself.

As a result, AOP programs will look very different in C++ in comparison to Java -- but what's most important is how the programmer is thinking about his or her design, not about how the code looks.

Therefore, AOP certainly is a development methodology.

  • 1
    +1. Noam Chomsky says that language is what defines cognition, and it is both constrained and based on the way you formulate your thoughts. In other words, you may approach everything as a language feature, but it will not be useful.
    – P Shved
    Jun 19, 2011 at 21:10
  • You use the phrase "development methodology" and then say it's about organizing code. That's not true - development methodology refers specifically to process. Examples of development methodologies are iterative, incremental, sequential, agile, and so on. AOP is not a development methodology. However, it is a programming paradigm.
    – Thomas Owens
    Jun 19, 2011 at 21:13
  • @Thomas: I guess we can agree to disagree there. :) Jun 20, 2011 at 15:37
  • I think the problem here is that there are many angles that need to be considered during software development: error handling, scope, encapsulation, etc. Each of those narrowly focused dimensions does not constitute its own paradigm or methodology. My question is really trying to uncover, "are aspects a narrow scope" like these features? If so, AOP is misnamed. Jun 20, 2011 at 16:02

There are two things at play here - programming paradigm versus software development methodology.

Yes, Aspect-Oriented Programming is a programming paradigm. It leverages certain language features in order to represent the constructs that are either necessary to carry out a task or to make code more readable. It's a technique that can be employed by a programmer. A lot of times, you see AOP used along side Object-Oriented Programming in order to remove cross-cutting concerns. However, you can implement aspect-oriented programming on top of a functional language as well. It's not necessarily an entirely new paradigm, but an extension to OOP and functional programming to alleviate known problems. The core reason why I believe that it should be considered a paradigm is that it changes the way you think about reaching a solution to the problem. Just like functional programming, procedural programming, logic programming, and object-oriented programming all have drastically different solutions to the same problem, aspect-oriented programming adds yet another solution to the problem set.

No, Aspect-Oriented Programming is not a development methodology. A development methodology is a framework that you can use to create a software system. It specifies what tasks you carry out and how you carry them out, from requirements through end-of-life. AOP says nothing about this. However, some programming paradigms have lead to development methodology approaches for the software lifecycle. There was an approach called Object-Oriented Software Engineering, which was developed by Ivar Jacobson which specified a complete lifecycle for designing and developing object-oriented systems, but has fallen out of favor and has been replaced by UML and the Rational Unified Process. I honestly don't see AOP influencing methodologies the same way OOP did. In fact, just looking at trends seems to indicate that methodologies should transcend the language and paradigms used to build the software. There might be AOP-focused modeling techniques and vocabulary used during design and development, but I don't see a full-blown methodology centered on AOP.

  • American Heritage dictionary defines paradigm as "A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline." Object-oriented programming feels clearly to me like a technique to model reality. In my coding experience, I have yet to find an applicable use case for AOP language support, and as open-minded as I see myself, at this point it appears to me an enormous leap to apply the paradigm label to aspects. Jun 20, 2011 at 3:48
  • @glenviewjeff That's not how the term "paradigm" is defined when referring to a programming paradigm. In this context, a paradigm is a method of solving a problem. Aspect-orientation is just that - you are using aspects to solve a problem. If you search for the definition of programming paradigm, the first few pages of Google searches agree with my definition. It's very common, especially in technical field, that words change meaning from their common usage.
    – Thomas Owens
    Jun 20, 2011 at 9:49
  • 1
    AOP is not a paradigm. It's a useful facility, but it's a feature in a landscape, not a landscape on its own. Jun 20, 2011 at 14:52
  • not that an unsourced Wikipedia sentence is a reliable reference, but it's certainly on par with a collection of unsourced Google results. The first sentence in the Wikipedia article on "programming paradigm" says "A programming paradigm is a fundamental style of computer programming." I believe this is completely consistent with American Heritage dictionary's definition of a paradigm. Jun 20, 2011 at 15:28
  • 1
    @Tom Anderson @glenviewjeff The reason that it is indeed a paradigm is that it changes the way you think about a problem. A feature makes it easier to solve a problem, but doesn't change the way you think. An example of a feature is a for-each loop - it doesn't change how you think about a problem involving iterating over a collection, but it makes it easier to do so. A paradigm drastically changes how you reach your solution, and I believe that AOP does this. Without AOP, your solution would be very, very different than with AOP.
    – Thomas Owens
    Jun 20, 2011 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.