Non ça ne sert pas qu'à ça, c'est juste l'exemple type, qui montre bien le problème que résouds la POA. Tu peux imaginer bien d'autres types d'utilisations (consulte les liens sur JAC de la news), par exemple rajouter un aspect "distribué" à ton application, etc.
Prenons un autre exemple : imaginons que tu programmes un soft de gestion du personnel. Tu en fait une belle modélisation orienté objet : tu organises ça en classes (genre une classe manager, une classe employé, etc.) et ta préoccupation est ainsi de modéliser les informations et les liens entre les personnes de la boite. Ton modèle peut servir également pour stocker les infos concernant les salaires. Il peut aussi servir à définir et garantir certaines règles de gestion, comme "un employé doit avoir au moins un manager", ou "le salaire doit être supérieur ou égal au smic".
En fait, si tu réfléchis en terme d'aspects, ton modèle mixe un aspect "'stockage' du personnel" avec un aspect "organisation du personnel", ainsi qu'un aspect "comptabilité" et un aspect "règles de gestion". La modélisation objet capture l'aspect "données" ('stockage' du personnel), mais ne capture pas de façon pratique les autres aspects. Avec l'AOP tu peux exprimer ces différents aspects de façon claire, et définir la façon dont ils doivent se combiner pour former ton programme final.
Si on pousse plus loin, on peut imaginer recombiner complètement les différents aspects d'un programme de façon à coller avec l'orientation voulue à un moment. En effet, on modifie très souvent un programme au cours de sa "vie" car les besoins évoluent, et le design de départ ne colle plus forcèment avec ce qui est attendu à un moment donné; non pas que le design de départ soit forcèment mauvais, mais il ne réponds plus exactement à ce qui est finalement demandé. Si le design de base est vraiment trop éloigné, on finit généralement par réécrire complètement le soft. Et bien, l'AOP peut être une réponse à ce genre de problèmatique, en autorisant la recombinaison des différents aspects.
A ce sujet, on peut consulter le projet Hyper/J, qui traite de la séparation des préoccupations ("Separation of concerns") de façon multi-dimensionnelle, et qui personnellement me parait une approche particulièrement intéressante de l'AOP (le projet semble un peu au point mort malheureusement) :
[^] # Re: Conférence sur la programmation orientée aspect et JAC, à Toulouse.
Posté par Nicolas Roard . En réponse à la dépêche Conférence sur la programmation orientée aspect et JAC, à Toulouse.. Évalué à 6.
Prenons un autre exemple : imaginons que tu programmes un soft de gestion du personnel. Tu en fait une belle modélisation orienté objet : tu organises ça en classes (genre une classe manager, une classe employé, etc.) et ta préoccupation est ainsi de modéliser les informations et les liens entre les personnes de la boite. Ton modèle peut servir également pour stocker les infos concernant les salaires. Il peut aussi servir à définir et garantir certaines règles de gestion, comme "un employé doit avoir au moins un manager", ou "le salaire doit être supérieur ou égal au smic".
En fait, si tu réfléchis en terme d'aspects, ton modèle mixe un aspect "'stockage' du personnel" avec un aspect "organisation du personnel", ainsi qu'un aspect "comptabilité" et un aspect "règles de gestion". La modélisation objet capture l'aspect "données" ('stockage' du personnel), mais ne capture pas de façon pratique les autres aspects. Avec l'AOP tu peux exprimer ces différents aspects de façon claire, et définir la façon dont ils doivent se combiner pour former ton programme final.
Si on pousse plus loin, on peut imaginer recombiner complètement les différents aspects d'un programme de façon à coller avec l'orientation voulue à un moment. En effet, on modifie très souvent un programme au cours de sa "vie" car les besoins évoluent, et le design de départ ne colle plus forcèment avec ce qui est attendu à un moment donné; non pas que le design de départ soit forcèment mauvais, mais il ne réponds plus exactement à ce qui est finalement demandé. Si le design de base est vraiment trop éloigné, on finit généralement par réécrire complètement le soft. Et bien, l'AOP peut être une réponse à ce genre de problèmatique, en autorisant la recombinaison des différents aspects.
A ce sujet, on peut consulter le projet Hyper/J, qui traite de la séparation des préoccupations ("Separation of concerns") de façon multi-dimensionnelle, et qui personnellement me parait une approche particulièrement intéressante de l'AOP (le projet semble un peu au point mort malheureusement) :
http://www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm(...)
http://www.alphaworks.ibm.com/tech/hyperj(...)