Aspects of Aspects

When I learned about Object-oriented programming, I thought it was about the coolest thing I had ever seen. The canonical example back in 1989 was shapes, so that you could create a polymorphic draw() method (this example still pops up a lot). So, I learned about OOP as a way to model problem domains. However, the only examples I saw for years out in the real world were all frameworks, like GUI frameworks or persistence stuff -- it was generally in the form of components to make constructing applications easier. Gradually, people started using OOP the way that I thought it should have been all along -- to model problem domains.

I think the same thing is happening right now with Aspects. While not as revolutionary as OOP, aspects still represent a key shift in thinking. But most of the examples you see these days are all in the boundary layers again -- logging, persistence, dependency injection, security, etc. Like OOP, once developers really grok what's going on with aspects, we'll start seeing it show up in the problem domain layer in places where it makes sense. Just like the really advanced OOP practitioners were doing it right early on, the aspect guys who are pushing the state of the art are pushing aspects into the problem domain right now. In 15 years, it will be as natural as polymorphism.