But not in the way it is implemented. It's much more like a service, in that it's not the protocol handler which decides when it is appropriate to use it. Or so it seems to me. --Ilja Preuss You are perfectly right and that's why I quoted the
word "aspect". In the most general sense, an aspect is a
unit of modularization for a crosscutting concern. This unit might as well be proactive or completely passive, it all depends on how it is implemented and which goals it pursues. Today, we suffer from AspectJ's definition of an aspect and we fail to recognize other kinds of aspects (and realizations thereof) when they come up.
Moreover, the way something is implemented does not drive the way the paradigm should be interpreted but the other way around. To follow up on the protocol handler example, in J2ME you use a Connection object and you don't really know what protocol underlies your connection, all you know (and what matters) is that you have a connection and that you can communicate with the rest of the world. The protocol handler in CLDC decides how to handle the bytes you send to it.
Finally, from
thefreedictionary.com:
[...]
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.
[...]
In other words, the aspect-oriented paradigm tends to see communication (which are handled by protocol handlers) as a crosscutting concern of a system, and thus, an aspect of the system in the AOP sense.
[ May 11, 2004: Message edited by: Valentin Crettaz ]