Ramnivas Laddad

Author
+ Follow
since Jul 23, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ramnivas Laddad

Congratulations to all winners. It was nice to be here.

-Ramnivas
12 years ago
Mark already clarified, but I will add a bit more...

Paras Jain wrote:
Aspect - It's like calling logging framework, the Process of logging


More like aspects is a programming element that hold all other AOP programming elements -- pointcuts, advice etc.


Advice - I am advising the AOP to call log methods on logging framework, like a method


Advice is extra code that you want to invoke when you reach points selected by your pointcut

12 years ago
You can think of
- aspect as a class-like concept.
- advice as an automatically called method
These two are usually understood easily.

Join point and pointcut concept take a bit longer. One way to think:
- Join points are like rows in database--they just exists much the same way methods just exists.
- Pointcuts are like SQL statements--they select join points just as SQL selects rows.

I hope this helps.

-Ramnivas
12 years ago
You have two options:
1. Use AspectJ tools, especially AJDT that will show you how classes are interacting with aspects
2. Use annotations and select join point based on those annotations. This way, class developer will see code such as @Transactional (almost similar to comments idea you mentioned) and know that certain AOP functionality is applied there.

-Ramnivas
12 years ago
Map this example (or even better something like transaction management, security, or concurrency control) and you will see that learning AOP and implementing aspects is far better than repeating code in hundreds of places. For example, see code in freely downloadable chapter 10 to see if that helps convincing yourself if AOP reduces complexity.

-Ramnivas
AspectJ in Action covers the following topics related to dynamic weaving (but doesn't use that term, since it is a quite an overloaded term):
1. Load-time weaving
2. Spring's proxy-based AOP (which occurs at runtime)
3. Enabling/disabling functionality added through aspects using JMX.

-Ramnivas
12 years ago
Just answered a similar question in another thread. For a more detailed answer, please read the first chapter (freely downloadable).

-Ramnivas
12 years ago
Adding members to another type doesn't violate encapsulation. Existing clients of that type continue to use the type as if it isn't modified. Only aspects (and other parts) that are aware of the introduced members utilize the type to provide additional functionality. As for access, by default aspects use the same access rules as Java. Specifically, aspects do not have access to private members of another type. AspectJ does have privileged aspects that can give access to private members, but its use should be (and usually is) limited to corner cases.

-Ramnivas
12 years ago
There is an incremental mode to 'ajc'. However, if you use Eclipse with AJDT, you don't need to worry about it, since incremental compilation is enabled by default.

-Ramnivas
12 years ago
AOP actually reduces technical complexity; however, it requires that developers working on the AOP portion of code understand it well. Like any other technology, AOP can be learned. So it becomes an issue of gaining competitive advantage by using AOP vs. putting effort in learning it.

-Ramnivas
I think the book will help such a project. But take a look at book's Table of Content to decide.

-Ramnivas
12 years ago
Any annotations: external and internal frameworks and custom annotations. For example, if you wanted to apply a retry logic, you could devise @Idempotent as a custom annotation and use execution(@Idempotent * *(..)) to select such operations. In a similar way, you can use @Transaction (Spring), @Secured (Spring Security), @Entity (JPA) etc. Please see my articles (http://www.ibm.com/developerworks/java/library/j-aopwork3 and http://www.ibm.com/developerworks/java/library/j-aopwork4) for more details -- but these are somewhat older articles so some information has changed since their publication.

-Ramnivas
12 years ago
There aren't really any technical reasons to not use AOP/AspectJ (of course, for AspectJ, the use of Java is a prerequisite). There are, however, non-technical reasons such as lack of an internal champion who understand AOP/AspectJ reasonably well, lack of understanding of OOP and AOP, and such.

Basically, this is not that different than if the question were to be change to "Why shouldn't we use Java/OOP?".

-Ramnivas
Take a look at the Table of Content for AspectJ in Action. You will see a range of problems AspectJ can help with.

-Ramnivas
12 years ago