J'ai testé un outil sympa pour faire de la POA à base de modèle graphique, jTagStudio ( http://www.electronic-experience.com ).
J'ai testé un outil sympa pour faire de la POA à base de modèle graphique, jTagStudio ( http://www.electronic-experience.com ).
Bonjour,
Effectivement la programmation orienté aspect n'a rien de révolutionnaire. Pourtant le coté intéressant à mon sens et de rester concentrer sur les problématiques métiers que l'on a à implémenter. A bas les try/catch, les logs, les gestions de sécurité qui pourrissent le code dans toutes les classes donc qui multiplient les lignes de code sans rajouter un niveau fonctionnel supplémentaire.
Je crois que comme dans l'ensemble des technos, l'aspect participe à rendre moins technique le code et plus métier. Les problématiques techniques et transverses étant implémentés en aspect.
Seul bémol aujourd'hui l'aspect ne fait pas encore partie d'un langage à part entière. En java il faut choisir entre la solution JBoss, AspectJ et bien d'autres qui ont chacun leurs avantages et leurs défauts.
La question à se poser, à mon sens, est d'abord de savoir si cette simplification du code grâce à la POA (que je trouve toute relative), est suffisante pour masquer la difficulté, le temps à passer en plus (tissage à faire, et j'en passe...) et l'apprentissage de la POA.
J'en doute fortement.![]()
Ce que tu dis est vrai pour toutes technique de génie logicielle en général. C'est toujours plus facile de développer comme un bourrin que de bien développer en suivant les préceptes du GL. La différence se ressent sur le long terme et à de grandes échelles, comme toujours dans ce domaine.![]()
Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS
Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android
Bonjour à tous.
Je découvre en ce moment le paradigme de "la programmation orientée aspect". Et en moi trotte une question: ce paradigme est il vraiment utile ou est-ce un effet de mode ?
Car sur le papier, c'est très beau de découper le programme en plusieurs aspects, de dire quand il doivent s'appeler et de laisser le compilateur faire le mix final pour obtenir un programme.
Mais en pratique, je trouve qu'il est impossibe de réaliser un programme juste avec ce paradigme. D'ailleurs, même les outils sont plus des sur-couches aux langages/outils existants. De plus, j'ai l'impression que la mise en oeuvre de la programmation par aspect se résume à du logging non intrusif.
Enfin, étant donné que les aspects sont totalement orthogonaux à l'application, j'ai aussi peur qu'on puisse faire faire à mon code n'importe quoi (rajouter des classes parentes ou des données alors que je n'ai rien demandé,...).
David Côme.
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Moi ce qui m'effraie le plus c'est que je ne peux plus être sûr de ce que va vraiment faire un bout de code : un aspect pourrait venir complètement modifier le déroulement des instructions, modifier des données, rajouter des effets de bord, etc... n'importe où. Ce qui signifie que pour comprendre un code je dois maintenant maintenir en permanence une carte des "jointpoint" utilisé par mes aspects en tête.
Je dois avouer que la perspective m'effraie ! D'un autre côté je n'ai jamais vraiment essayé la programmation orienté aspect et suis donc probablement mal placé pour critiquer. Néanmoins, comme toi, les seuls usages raisonnable de la technique qui m'intéresseraient seraient pour des injections de code de débuguage ou de logging, du code qui n'interfère pas avec son contexte.
Apparemment il y a des équipes qui travaillent avec ces technologies sur des projets réels.
--
Jedaï
C'est vrai, on a aucun contrôle dessus. Et c'est encore pire avec les aspects sur les classes ou comment se retrouver avec une classe parente et des fonctions virtuelles sans le vouloir.
Débuguage, logging, invariant de classes, gestion des mutex/lock, voici à quoi je pense pouvoir utiliser les aspectsJe dois avouer que la perspective m'effraie ! D'un autre côté je n'ai jamais vraiment essayé la programmation orienté aspect et suis donc probablement mal placé pour critiquer. Néanmoins, comme toi, les seuls usages raisonnable de la technique qui m'intéresseraient seraient pour des injections de code de débuguage ou de logging, du code qui n'interfère pas avec son contexte.
Aurais-tu des noms de projets (open source ou académique) pour voir comment ils utilisent la chose ?Apparemment il y a des équipes qui travaillent avec ces technologies sur des projets réels.
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Un lien utile : PostSharp.
Sinon, la programmation orientée aspect... L'idée c'est surtout de modifier le comportement des objets en annotant le code plutôt qu'en ajoutant du code.
Un exemple tout con est celui de INotifyPropertyChanged.
Vous préférez ceci :
ou cela :
Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 class Toto : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; void Notify(string propertyName) { if ( PropertyChanged != null ) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } Guid _ID; string _Name; public Guid ID { get { return _ID; } set { _ID = value; Notify("ID"); } } public string Name { get { return _Name; } set { _Name = value; Notify("Name"); } } }
Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 [NotifyPropertyChanged] class Toto { public Guid ID{get; set;} public string Name{get; set;} }
C'est le but même de l'orienté aspect: pouvoir modifier complètement certaines fonctions sans même devoir y toucher.
Bien sur c'est à prendre avec des pincettes. Il n'est pas question de modifier de tout au tout le comportement d'une fonction ou méthode. Il faut la laisser vivre tant qu'elle fonctionne bien.
On pourra se servir des aspects pour ajouter des petites features à ces fonctions.
Je prends pour simple exemple une fonction que j'avais dans un serveur web simple en python, qui était chargée de retourner simplement le contenu d'un fichier.
Cette fonction était une one liner, un simple open et read lançant une exception IOError si le fichier n'avait pas pu être lu (seule raison ici: c'est un dossier).
Autour de cette fonction, et selon la config, j'avais rajouté un aspect qui, en cas d'IOError, allait tout simplement lister le contenu du dossier et le retourner en faisant disparaître l'erreur.
Inutile me direz-vous, on peut très bien faire ça sans les aspects.
Oui.
D'ailleurs on peut très bien faire de l'héritage et du polymorphisme sans les objets.
A côté de ça, l'orienté aspect permet de nombreuses autres choses, qui ne sont limitées que par l'imagination des gens.
J'ai aussi créé (tjs en python), des aspects qui se chargaient de récolter tous les objets d'une classe, pour ensuite pouvoir rechercher des objets qui avaient, par exemple, la propriété age égale à 25, la propriété lastName égale à "Dupont" etc.
Comme tu l'as dit, ça peut aussi servir à la synchronisation, au logging.
Ca sert au Unit Testing même, qui fonctionne merveilleusement bien avec.
Quelqu'un m'a même rapporté qu'il se servait de ma librairie pour enregistrer l'état des objets lorsqu'ils interagissent entre eux.
De plus, comme les aspects permettent de faire disparaître des erreurs, ils peuvent contribuer à rendre le code plus propre, éliminant une grande majorité de try/catch et de scénarios alternatifs.
Et pour finir, l'orienté aspect permet de supprimer réellement du code certaines options selon la config, dans les langages dynamiques.
J'ai eu droit à un léger aperçu des utilisateurs de l'orienté aspect. De ce que j'en ai vu, il s'agit plutôt de gens issus du monde professionnel. Du moins ce sont eux qui se manifestent.
PS: la meilleure solution orientée aspect pour Python, c'est Aspyct. De mon point de vue c'est la meilleure du moins, puisqu'elle convient parfaitement à mes attentes: c'est la mienneElle est en suspens pour l'instant, cause exams
![]()
Bonjour,
Cela fait un peu plus de deux ans que j'ai découvert la programmation orienté aspect. J'utilise AspectJ pour mes projets perso.
On parle souvent de faire du loggin non intrusif ou la gestion des transactions avec les aspects. Mais on peut faire des choses beaucoup plus intéressantes.
Par exemple, j'ai couplé les annotations avec les aspects pour faire de l'IOC.
J'ai des classes qui possèdent des attributs qui ont comme type une interface, à la création de l'objet j'ai un aspect qui sert à renseigner ces attributs avec une implémentation spécifié dans un fichier de configuration.
Je fais de même avec l'affectation de propriété.
Pour moi l'aspect c'est une manière plus élégante de modifier du code statiquement ou dynamiquement. Rien de révolutionnaire, mais c'est très pratique.
A+
Hydraland
Partager