I've heard many times about the aspect-oriented programming, mostly that it is the "next generation" technology in programming and is going to 'kill' OOP.

Is it right? Is OOP going to die or what can be reason for that?


Any time someone tells you that one software technology will kill another one or dominate the whole market/use/audience, remember this :

A sane (dynamic but stable) ecosystem is made of a variety of widely different species.

That means that any new hyped technology will go through the hype curve and in the end will find it's specific(s) purpose through time and experience with it.

Hype Curve

That also mean that such an extreme concept as aspect-oriented programming is useful if it's needed, meaning, not always and not very often, because of implied costs.

But it already have it's place, like OOProgramming, like generic programming, like functional programming, like procedural programming, etc.

Did you notice that the languages that are the more used (and controversly popular) and widely spread in real life are "not pure"? That's because allowing several paradigms makes them more flexible to change of context through time and they fill more usage niches.

  • 1
    +1 for 'not pure'. Pure OOP languages are notably dead, except for very niche uses/academics. – jv42 Jun 30 '11 at 13:54
  • What would we consider a pure OO language? Smalltalk? – Zhehao Mao Jun 30 '11 at 14:45

OOP isn't going to die because of AOP. AOP adds some value, but it lives in perfect coexistence with OOP. I don't think that functional programming will kill OOP either. OOP is too good a fit for many kinds of problem domains, it wouldn't make sense to replace it with the functional paradigm.

  • 6
    The classic example where OOP is a good fit are GUIs. It's hard to imagine an API for a GUI toolkit that is not OO, even if the language isn't. (Granted, that's not how the term problem domain is usually used) To give an example of a real problem domain where OOP is a good fit: Warehouse automation. Modelling the storage and retrieval vehicles and their activities is where OOP feels like a natural fit. – user281377 Jun 29 '11 at 9:48
  • 2
    @ammoQ, GUIs are horrible when expressed in OO. That's the reason why all the APIs are drifting towards DSLs (WPF and alike). It is not hard to imagine, say, Tk - no single trace of OOP there, but still it is great (for programming, not for its look&feel), much better than any of the overbloated Java OO toolkits. OOP fits really well into any agent-based simulations (like those you've listed), but it is a tiny proportion of the existing problems. – SK-logic Jun 29 '11 at 10:02
  • 7
    Looking at the first examples of tk I could find, how is that not OO? From the tutorial: "Widgets are objects, instances of classes that represent buttons, frames, and so on." tkdocs.com/tutorial/concepts.html Even more, DSLs itself are very reliant on the OO programming. So I'm not really understanding what you are tryign to say? – Inca Jun 29 '11 at 10:16
  • 2
    You simply re-asserted your statement without actually explaining why. I'm curious about this too; I'm tempted to suspect the issue isn't so much that Tk isn't object-oriented as your definition of OO is too narrow to encompass it. – jhocking Jun 29 '11 at 14:55
  • 4
    @Sk-logic, @ammoQ, @Raynos, @jkocking, I promoted it into a question of its own: programmers.stackexchange.com/questions/88385/… I would be very interested to have more explanations on this, I am very interested to learn. – Inca Jun 30 '11 at 9:25

Paradigms come and go, but legacy code is forever. There's always going to be C++ code to maintain, so OOP is never going to die out completely.

  • 6
    +1 for a truly brilliant phrase: "Paradigms come and go, but legacy code is forever" – NoChance May 31 '12 at 6:07

Short answer: No, I don't think so.

Longer answer: From what I understand of AOP, it's not a programming paradigm in itself (as in, it doesn't replace OOP), but more of an addition, a toolkit that helps you write shorter methods, simpler, single-responsibility classes, etcetera. But it doesn't replace OOP.

The thing that does (at least in part) replace or adds to OOP is functional programming, which actually is a different programming paradigm (although it can be mixed with OOP, for example in the Scala programming language). It prefers immutable datastructures and all kinds of fancy features that tend to frustrate OOP developers, particularly when it comes to concurrency.

  • Functional <-> Imperative is the line. OOP is parallel to it. I think procedural is on the other end of OOP but I'm not sure. Of course it's amusing that Functional paradigm is older then the OOP paradigm :) – Raynos Jun 29 '11 at 8:59
  • 2
    @Raynos, there is no straight line. OOP is just one tiny metalinguistic abstraction inside a huge (infinite) set of possible abstract languages. And of course it is extremely stupid to limit yourself to any one of them. – SK-logic Jun 29 '11 at 9:13

OOP is talked about less these days since its assumed to be the de facto approach in many situations. AOP never got off the ground as any kind of mass movement.



I remember hearing about Aspect Oriented Programming for the first time sitting in a OOPSLA '97 Tutorial. They said it was going to kill OO way back then. Since then, OO has only grown beyond wildest expectations. AOP, is still barely known with essentially no impact on the computing industry. I think the answer is obvious that AOP is no OO killer.


Look at some existing AOP systems. They depend on you having some code written in some form -- for example, Spring AOP relies on you having your methods defined on a class. Castle Windsor supports it in C#, which is an object oriented language.

You could theoretically switch from OOP to structured programming and still keep AOP, but in practice, that would be difficult. It's easy to subclass something, override the relevant method to call the appropriate before/after filters, and pass that on in the process of dependency injection.

It's bloody hard in comparison to rewrite static method calls to route to a trampoline method designed to call the user-defined filters.

So from a common implementation standpoint, AOP requires OOP.


While OOP is certainly not a silver bullet, the same can be said for AOP. It supports component based design, however in the grander scheme your components are the new objects and the component interfaces are basically a transactional list of methods, which is NOT true OOP.

Further AOP and component based design support an Anemic Data Model, which smarter people than myself hold criticism of.


(I know the article above is old, yet surprisingly relevant)

The bottom line is that AOP systems are here to stay but they are far from perfect as well. No system is perfect.

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