I've bought into the AOP thing a couple times, and every time it has bitten me (or my coworkers) in the ass.
I fully admit that it may be too much power for mine (and colleagues) small brains, but has anyone ever actually seen AOP work, in practice?
It sometimes reduces coding efforts, but it is the living embodiment of the saying, "If you're as smart as you can be when you write it, how will you ever debug it?"
It's just too much magic spread over too wide an area. I'd much rather have more explicit patterns being used that people can understand, find, reason about, and debug - code reuse is a means to an end, not the end itself.
I've applied the technique in a project once with a pretty nice effect. I think the key requirement for AOP is that your code really is very clean, and to never influence logic in your main code in any other way than stopping it.
I.E, if you insist on catching exceptions in your crosscuts, don't go trying to fix the exception by modifying state. Either kill the thread, or let the original logic deal with it.
Our project was a bit of a laboratory environment. It was a university course that meant to test our ability to apply Patterns of Software Development (i.e. GoF) by having us implement a board game called Bohnanza (basically a heavily simplified Magic: The Gathering).
Our approach was to fully focus on implementing the business logic in a correct and test-driven fashion. In the weeks we spent on implementing the business logic we never implemented any GUI.
Then when it was done instead of polluting the business logic with the traditional MVC architecture, we designed a GUI that was layered on top of the business logic through AOP.
The GUI was just observing through cross cuts the transitions of the games state machine, rendering the relevant game elements and making available the valid inputs. We were one of the few teams who managed to have both a correct game logic and a fully functioning GUI as well as a test suite with good coverage.
So much AOP negativity on here. I haven't specifically used AOP in a project, but I do recognize huge value in its concepts. Many of the techniques here also have other names in other traditions, but if you get past the rather awkward terminology, the concept of factoring separate concerns into reusable and independently testable chunks is really useful, by any name.
My negativity comes from experience. I also like the theory and concept of it, but I haven't found it to help in other than very specific circumstances, and quite destructive in time and understanding when used even slightly outside those.
Terminology had nothing to do with the issue, in my particular experience.
Once had a job interview at a software consulting company. They had a number of finished projects for high profile customers and they claimed that they use AOP for their projects. Turned down the offer though because I didn't like the people too much. ;)
Comments
I've bought into the AOP thing a couple times, and every time it has bitten me (or my coworkers) in the ass.
I fully admit that it may be too much power for mine (and colleagues) small brains, but has anyone ever actually seen AOP work, in practice?
It sometimes reduces coding efforts, but it is the living embodiment of the saying, "If you're as smart as you can be when you write it, how will you ever debug it?"
It's just too much magic spread over too wide an area. I'd much rather have more explicit patterns being used that people can understand, find, reason about, and debug - code reuse is a means to an end, not the end itself.
Again, maybe I'm just not enlightened enough.
I've applied the technique in a project once with a pretty nice effect. I think the key requirement for AOP is that your code really is very clean, and to never influence logic in your main code in any other way than stopping it.
I.E, if you insist on catching exceptions in your crosscuts, don't go trying to fix the exception by modifying state. Either kill the thread, or let the original logic deal with it.
Our project was a bit of a laboratory environment. It was a university course that meant to test our ability to apply Patterns of Software Development (i.e. GoF) by having us implement a board game called Bohnanza (basically a heavily simplified Magic: The Gathering).
Our approach was to fully focus on implementing the business logic in a correct and test-driven fashion. In the weeks we spent on implementing the business logic we never implemented any GUI.
Then when it was done instead of polluting the business logic with the traditional MVC architecture, we designed a GUI that was layered on top of the business logic through AOP.
The GUI was just observing through cross cuts the transitions of the games state machine, rendering the relevant game elements and making available the valid inputs. We were one of the few teams who managed to have both a correct game logic and a fully functioning GUI as well as a test suite with good coverage.
So much AOP negativity on here. I haven't specifically used AOP in a project, but I do recognize huge value in its concepts. Many of the techniques here also have other names in other traditions, but if you get past the rather awkward terminology, the concept of factoring separate concerns into reusable and independently testable chunks is really useful, by any name.
My negativity comes from experience. I also like the theory and concept of it, but I haven't found it to help in other than very specific circumstances, and quite destructive in time and understanding when used even slightly outside those.
Terminology had nothing to do with the issue, in my particular experience.
Once had a job interview at a software consulting company. They had a number of finished projects for high profile customers and they claimed that they use AOP for their projects. Turned down the offer though because I didn't like the people too much. ;)