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.
Comments
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.