Summary
More precisely, "Does Aspect Oriented Programming (i.e. AOP) supercede Component Models?". It's an interesting question, something we all would like to know before the AOP hype machine gets to full gear. To answer it, let's get our definitions straight first.
Advertisement
More precisely, "Does Aspect Oriented Programming (i.e. AOP) supercede Component Models?". It's an interesting question, something we all would like to know before the AOP hype machine gets to full gear. To answer it, let's get our definitions straight first.
AOP can be simply defined as the ablility to assert quantified statements over programs written by oblivious programmers. Special emphasis on the word oblivious.
2. A mechanism of encapsulation that can be dynamically introspected.
3 . [omitted for brevity]
4. A defined lifecycle that conforms to the requirements of a Container.
5. A protocol for interacting with the container. This covers, how to find other components and their factories, how to reference and invoke other components, etc. In otherwords, the functionality you have for POJOs used in the context of the container.
Clearly characteristics 1 and 2 are covered by the AOP definition. However characteristic 4 and 5 of component models are direct opposites of the "oblivious" requirements of AOP. Lifecycle can of course be introduced by using AOP "introductions". However, the notion of a context is conspicously absent in our present notion of AOP.