Talk:Aspect oriented programming
What is the task here? --Rdm 19:10, 9 June 2011 (UTC)
- While it does have some code examples, I think this is supposed to be more of an informational page. It's not marked as a task, but it was made by an anonymous user who probably didn't know the process. --Mwn3d 20:39, 9 June 2011 (UTC)
- It's not very informational either. It doesn't say what AOP is or why you might want to do it, but at least it includes a long rambly example in C, a language which I'd have called inimical to AOP in the first place… I can't even tell if that's because they “get it” much more profoundly than me, or much less. The evidence is consistent with both interpretations! –Donal Fellows 23:57, 9 June 2011 (UTC)
- I only made a guess at intent. I can't say anything about the quality. I don't understand AOP very well either. If someone wanted to improve the info here that'd be great. --Mwn3d 01:05, 10 June 2011 (UTC)
- In my experience, AOP is an attempt to address the issues a person might want to address using a Domain Specific Language, but without the conciseness, nor the modularity (with strong lip-service to the concept of modularity, but what I have seen in implementations does not align with my feelings about modularity). Now, granted, the theory (MVC++) usually sounds great, but the examples I have seen (Observer++) have made me want a good DSL implementation. -- --Rdm 11:31, 10 June 2011 (UTC)
- AOP allows you to wrap cross-cutting functionality round other code without disrupting that other code particularly. The way in which it is most strongly used in frameworks like Spring is to provide transactions round methods, so that all a method has to do is to work with the data and let the aspect handle the transaction (including things like rolling the changes back if an exception is thrown). Having tried to write transaction-handling code without AOP, using an aspect to handle it is far simpler; it's genuinely difficult to get transaction handling correct and it makes the code very ugly when you do, but splitting it off into its own concern (the “aspect”) means that the business logic is separated from the complexity. It's also used for things like logging, cacheing, security enforcement, etc. All things that are typically orthogonal to the core of what's going on. The degree to which aspects should be applied transparently or with some kind of explicit marker is something which seems to divide practitioners; I'm more of an “explicit” guy as its easier to see what's going on when maintaining the code… –Donal Fellows 15:18, 10 June 2011 (UTC)
- In my experience, AOP is an attempt to address the issues a person might want to address using a Domain Specific Language, but without the conciseness, nor the modularity (with strong lip-service to the concept of modularity, but what I have seen in implementations does not align with my feelings about modularity). Now, granted, the theory (MVC++) usually sounds great, but the examples I have seen (Observer++) have made me want a good DSL implementation. -- --Rdm 11:31, 10 June 2011 (UTC)
- I only made a guess at intent. I can't say anything about the quality. I don't understand AOP very well either. If someone wanted to improve the info here that'd be great. --Mwn3d 01:05, 10 June 2011 (UTC)
- It's not very informational either. It doesn't say what AOP is or why you might want to do it, but at least it includes a long rambly example in C, a language which I'd have called inimical to AOP in the first place… I can't even tell if that's because they “get it” much more profoundly than me, or much less. The evidence is consistent with both interpretations! –Donal Fellows 23:57, 9 June 2011 (UTC)