I am getting more interested in Aspected Oriented Programming since it has potential to organize code much more cleanly eliminating duplication. Adopted judiciously it can also help separation of buisness logic and infrastructure code ( logging, authentication etc) to a very good extent. This approach is just moving from infancy to early adoption. Anyone using/have used AOP. For big projects/big teams how easy/smooth is the transition? Are you taking the refactoring/low risk approach (refactoring non core components like logging etc)?I have been programming in Java for many years now and kind of losing touch with C++. What are the latest trends in C++ to enable code maintainability, removing code duplicity and code demarcation ( clean separation of buisness and infrastructure).To ensure better compliance and buisness auditing what coding techniques are you adopting?For more information on AOP look into http://www2.parc.com/csl/projects/aop/

Designers have been openly criticizing the major problems raised by the use of the GoF patterns in their initially proposed implementations: confusion, indirection, encapsulation breaching and inheritance. These were further noticed as being special cases of the two problems of “code scattering” and “code tangling” exemplified herein in some of the previous postings (Flyweight vs Singleton, discussion).The 14 categories under which GOF patterns are described could be easily encapsulated in the aspect-oriented ones: Participants; Collaborations (in most of the patterns, communications are reduced to the collaboration protocol); Implementation (there are often several possible alternatives for structuring patterns); and finally Consequences (analysis the impact of various alternative structures on the application). The initial 23 patterns are most useful but should be tailored under context. Specific institutions should developed their own Pattern framework with which newcomers should get acquainted prior to any check-in. Pattern intensive legacy-code is more easily reusable but could as easily attain nightmarish maintenance problems, furthermore, this approach lacks the gluing-stuff aspects provide. I have worked for a major Telecom multinational, their legacy code was crammed with patterns, even so, a major in-house refactoring task spitted out almost 35K of useless code! (we ended up, implementing Fowler´s smells beforehand, in order to trim it down).I agree totally with Dr. Cuch´s approach, in fact, he has devoted a single book to PAC which I my humble opinion is the most useful pattern you find (although it looks more like the MVC on steroids) but we should also pay attention to lower-level coding issues, instead of delving solely on high-level design. (´aspects´ are nearer to use-cases than patterns, in fact). Furthermore, some of the object-oriented design patterns (Visitor for example) just disappear when aspect-oriented programming mechanisms are used. However, object-oriented design patterns are familiar to most of the software architects, hence, the name and description of the patterns should always subsist. Some Gurus like Ivor Jacobson, already began the aspect-oriented revolution. We should try to follow.The Janitor.

AOP is the new silver bullet ?(in the sens of Brooks' Mythical Man Month).In 1990, OOP was the silver bullet (or so we thought).

Dr. Cuch, you´re being a bit unfair about this... come on!That´s not quite true and you know it better than the mere mortals reading these threads.

QuoteOriginally posted by: SierpinskyJanitorDr. Cuch, you´re being a bit unfair about this... come on!That´s not quite true and you know it better than the mere mortals reading these threads.Please explain. I am being objective. Software is evolving! and getting better. Main concern for a technology is CRITICAL MASS. Is that so for AOP?Have a look at thie paper tape program if you are not convinced.

Just out of interest, are there any large-scale production systems using AOP?Haven't looked into it too much apart from the classical examples of adding logging to things after the fact,session management in server code e.g. apply session management aspect to some other stuff and bingo, instance multi-user server..(or something like that!)Cheers,/Mark

We had an AOP thread a while back, trying to come up with other potential uses. It's definitely an interesting technology, but I think many of the problems it will cause are not even clear yet. When you crosscut, you are changing an existing implementation in a way that breaks the assumptions that were in place when the code was written. It's powerful, but is it ready? -t.

tristainreid,That precisely is the point. As Pat says AOP is a to some extent a pardigm shift like procedural to OOP. Since it is so new a low risk approach is to refactor logging, generic exceptions etc is preffered approach.Eventually as the teams get more proficient and understand how it reduces drudgeryacceptance will follow. Also as cross cutting addresses generic problems it will reduce the code duplication but cant eliminate it.When we first started implementing test first (XP approach) some resistance was there but now people understnads its benefit and accept it whole heartedly.

i was thinking that one good way to use aop would be to check properties for null and replacing null strings with empty ones. with aop I can do it with a wildcard, so I can apply it to all my methods at once! isn't that great! that way, the method body itself is more clear, and only deals with business logic, rather than boring parameter checking, which would be the same on all the methods anyway, so aop saves me a lot of redundant code.does anyone see any problems with this type of 'solution'? i'm hoping someone will come up with an ide that TRULY makes aop work as it should. if you are looking at a section of code, you should have the ability to see ALL of the code that will be run there. A good aop IDE would have the ability to alternately show/not show the code that will be run for each method, even if the method is not explicitly named as the cut point. also new testing tools, old notions of code coverage are broken by aop. i think eclipse or some other open source project is the only place we'll realistically see these kinds of tools anytime soon.this is what I mean by not ready. i think it's a great idea, and has wonderful potential, and should be discussed a lot. i just think i won't realistically be using it in any kind of production environment for the next 5 years.-t.

tristanreid! Couldn´t agree more with you. Check these guys, they must be among the most original sw refactoring engineers / IDE developers nowadays!

Agree that they seem to be introducing innovations faster than any other IDE.Part of the credit is also due to their competition http://www.artima.com/lejava/articles/e ... ture.htmlI think best part of IntelliJ is the static analysis - amazingly powerfulI've been waiting to get my hands on http://www.artima.com/weblogs/viewpost. ... =116895for about three years.

>I've been waiting to get my hands on http://www.artima.com/weblogs/viewpost. ... ead=116895> for about three years. That's a long wait!