I've been following AOP (cautiously) for some years now. Here's a few salient points for those who don't have $250 to splash out.
The underlying principle of AOP is about "separation of concerns", a term introduced by Dijkstra back in 1974. Separation of concerns is a Good Thing[tm], but there's more than one way to do it. It's a conceptual thing more than it is any one particular implementation technique.
Both structured and OO programming offer techniques that allow the hacker to more clearly separate concerns: by organising their code into subroutines, modules, objects, methods and so on. The problem with OOP is that real world problems don't always break down into a set of clearly defined, independant object classes. In some cases you can end up with a problem fragmented into so many small pieces that you can no longer see the wood for the trees.
AOP tries to address this by allowing you to identify those concerns that don't fit neatly into an object model. These "cross-cutting" concerns are typically things like logging, debugging and security that affect many of the objects in your system. If you decide to change the way logging is handled, for example, you don't want to have to go and edit every single object that generates logging information. But that's often what happens in OO based systems - you design your class hierarchy with Products, Customers, Orders and other real-world entities in mind and implement them as "black-boxes" with internal functionality neatly hidden away. That's fine when the functionality really is local to the object, but not when it relates to a system-wide aspect like logging, etc. These are the kind of undesirable artifacts that can arise from the decomposition of a problem into objects.
However, that's not to say that there aren't ways of achieving the good parts of AOP in a non-AOP language. Many Design Patterns are examples of separating concerns. The Model/View/Controller and Model/Visitor patterns come immediately to mind. Going back to the early logging example, we could implement this in AOP fashion in an OO language, by creating a "Logger" object which implements all the logging functionality. Just make sure all your other objects delegate to the logger for logging rather than trying to do it themselves. Now you have all your logging code in one place, and you just have to worry about how you're going to pass the logger object around so that all your other objects can call on it... (and this is often the start of the rest of the problems...)
So AOP-a-like can be done in OO languages, but most OO languages aren't really cut out for it - you have to code the magic manually if you want it. Hence the rise of AOP languages (usually just bolt-on syntax additions to existing languages) that make this process that little bit easier.
AOP in Java does smell a little like GOTO, IMHO. In brief, it uses "join points" to connect different aspects together (e.g. call this logging method just before calling that other method). One can certainly argue that it's a more structured form of GOTO, but I believe the same fundamental problems remain: control flow jumping all over the place, with actions-at-a-distance waiting to catch out the unsuspecting programmer.
So my advice on AOP would be to treat it like OOP, XML, Java, and all the other "silver bullets" that over the years have claimed to be the next big thing that will save our collective software sanity. Recognise the problem that it's trying to solve, realise the benefits of the particular solution(s) presented, and ignore all the hype!
For those who don't already know, the Template Toolkit (TT) is the template presentation engine on which Slashdot runs.
The page that you're looking at right now is generated by TT, as is every other Slashdot page that has been served over the last few years (since Slash version 2.0). So TT may not be the best known technology, but it's been out there helping to build web sites (including some very high profile ones) for a number of years now.
Those who use it tend to swear by it (and occassionally at it), but I'm the guy who wrote it so you can't trust anything I say.:-)
One final point of clarification, TT is a template language written in the Perl programming language, but you don't need to know or learn any Perl to use it. That was one of the original design goals - to allow you to do things like variable substitution, include templates, if/else conditions, loops, etc., using a simple (non-Perl) meta language that web designers and other non-programmers can easily get their heads around.
However, it's not just a toy language. It also provides a rich set of hooks for those people who are "real" programmers who want to extend it to interface with back end databases, ecommerce systems, image libraries, or pretty much anything else you can imagine.
Keep simple things simple, and make hard things possible.
Slashdot Mirror
I've been following AOP (cautiously) for some years now. Here's a few salient points for those who don't have $250 to splash out.
The underlying principle of AOP is about "separation of concerns", a term introduced by Dijkstra back in 1974. Separation of concerns is a Good Thing[tm], but there's more than one way to do it. It's a conceptual thing more than it is any one particular implementation technique.
Both structured and OO programming offer techniques that allow the hacker to more clearly separate concerns: by organising their code into subroutines, modules, objects, methods and so on. The problem with OOP is that real world problems don't always break down into a set of clearly defined, independant object classes. In some cases you can end up with a problem fragmented into so many small pieces that you can no longer see the wood for the trees.
AOP tries to address this by allowing you to identify those concerns that don't fit neatly into an object model. These "cross-cutting" concerns are typically things like logging, debugging and security that affect many of the objects in your system. If you decide to change the way logging is handled, for example, you don't want to have to go and edit every single object that generates logging information. But that's often what happens in OO based systems - you design your class hierarchy with Products, Customers, Orders and other real-world entities in mind and implement them as "black-boxes" with internal functionality neatly hidden away. That's fine when the functionality really is local to the object, but not when it relates to a system-wide aspect like logging, etc. These are the kind of undesirable artifacts that can arise from the decomposition of a problem into objects.
However, that's not to say that there aren't ways of achieving the good parts of AOP in a non-AOP language. Many Design Patterns are examples of separating concerns. The Model/View/Controller and Model/Visitor patterns come immediately to mind. Going back to the early logging example, we could implement this in AOP fashion in an OO language, by creating a "Logger" object which implements all the logging functionality. Just make sure all your other objects delegate to the logger for logging rather than trying to do it themselves. Now you have all your logging code in one place, and you just have to worry about how you're going to pass the logger object around so that all your other objects can call on it... (and this is often the start of the rest of the problems...)
So AOP-a-like can be done in OO languages, but most OO languages aren't really cut out for it - you have to code the magic manually if you want it. Hence the rise of AOP languages (usually just bolt-on syntax additions to existing languages) that make this process that little bit easier.
AOP in Java does smell a little like GOTO, IMHO. In brief, it uses "join points" to connect different aspects together (e.g. call this logging method just before calling that other method). One can certainly argue that it's a more structured form of GOTO, but I believe the same fundamental problems remain: control flow jumping all over the place, with actions-at-a-distance waiting to catch out the unsuspecting programmer.
So my advice on AOP would be to treat it like OOP, XML, Java, and all the other "silver bullets" that over the years have claimed to be the next big thing that will save our collective software sanity. Recognise the problem that it's trying to solve, realise the benefits of the particular solution(s) presented, and ignore all the hype!
For those who don't already know, the Template Toolkit (TT) is the template presentation engine on which Slashdot runs.
The page that you're looking at right now is generated by TT, as is every other Slashdot page that has been served over the last few years (since Slash version 2.0). So TT may not be the best known technology, but it's been out there helping to build web sites (including some very high profile ones) for a number of years now.
Those who use it tend to swear by it (and occassionally at it), but I'm the guy who wrote it so you can't trust anything I say. :-)
One final point of clarification, TT is a template language written in the Perl programming language, but you don't need to know or learn any Perl to use it. That was one of the original design goals - to allow you to do things like variable substitution, include templates, if/else conditions, loops, etc., using a simple (non-Perl) meta language that web designers and other non-programmers can easily get their heads around. However, it's not just a toy language. It also provides a rich set of hooks for those people who are "real" programmers who want to extend it to interface with back end databases, ecommerce systems, image libraries, or pretty much anything else you can imagine.
Keep simple things simple, and make hard things possible.