Discussion :

[max44410]

Bonjour,

Pour ma part, j'ai suivi des cours de programmation par contrat avec Eclipse (en université). c'est très interessant car avec cette méthode de programmation on ne peut pas faire abstraction des specifications, on les retrouves dans chaque méthodes ou fonctions. les tests unitaires découlent des conditions que l'on s'est fixées auparavant.

Pour ma part, c'est une méthode de programmation robuste avec laquelle il est plus facile de ne pas avoir de bug ou de mauvaise surprise. Bien sur la partie analyse des post-conditions, pre-conditions, des conditions initiales, ... sont très importantes, ce sont elles qui nous permettes d'etre plus sur du fonctionnent de notre application. De plus cela permet de se rapprocher un plus du monde réel... je veux dire par là que les conditions de validations correspondent généralement au problème réel. D'ailleur outre la programmation cette méthode peut être appliquée dans tout autre projet.

Pour ma part c'est l'avenir de la programmation, ce qu'il manque ... c'est un langage spécifique, car nous nous avons travailler avec JAVA et une bibliothèque qui permet de mettre en place cette méthode de programmation. Pour finir je crois me rappeler que cette méthode n'est pas si récente que cela, je me rapel que des intervenants était venus lorsque j'étais en BTS (3-4 ans) nous présenter cela.

[Hephaistos007]

Saches que le langage Eiffel supporte la programmation par contrat. Et quel rapport avec la programmation par aspect ?

[Captain_JS]

En fait ce que dit est expliqué dans le lien http://www-igm.univ-mlv.fr ..., c'est du service. Certaines personnes ont appelé Aspect ce que d'autres appelent maintenant Service.

Le fait que "chaque unité implémentée (Aspect) reste inconsciente du fait que les autres unités peuvent l’instancier en tant qu’aspect" exprime tout ce qu'est un service.

Maintenant ma question est : pourquoi mettre cette "logique" derrière un mot comme Aspect (qui moi ne m'évoque rien ), alors (à mon avis) que si on parle de service, ça parle à tout le monde.

Personnelement ça me fait marrer de voir qu'on commence seulement à en parler (je dis ça parce que ce post est alimenté) alors que des services sont utilisés depuis quelques temps déjà.

[Hephaistos007]

Maintenant ma question est : pourquoi mettre cette "logique" derrière un mot comme Aspect (qui moi ne m'évoque rien ), alors (à mon avis) que si on parle de service, ça parle à tout le monde.

Les services fonctionnels (métiers) conserve cette dénomination. Les services non-fonctionnels sont appelés aspects pour (a) les différencier, (b) dénoter leur rôle transversal. Par ailleurs le terme aspect convient bien. La sécurité, les transactions, la persistance ne sont que les aspects d'une architecture. D'ailleurs on peut doit pouvoir les enlever/ajouter à tout moment, cela ne remet pas en cause la logique métier.
Tu as la réponse à ta question.

Personnelement ça me fait marrer de voir qu'on commence seulement à en parler (je dis ça parce que ce post est alimenté) alors que des services sont utilisés depuis quelques temps déjà.

Le retard est - malheureusement - celui qui existe toujours entre le monde de la recherche et celui de l'entreprise. Les chefs de projet n'ont qu'à s'intéresser un peu plus à ce qui se fait chez les chercheurs. La "veille technologique" est sur tous leurs CV mais peu en font réellement.

[®om]

Je pense pour ma part que ça va êter adopté comme la programmation par contrat l'a été. Il suffit d'attendre que un petit peu que ça se développe. Appemment ça marche bien, c'est robuste et cohérent ce qui n'est pas toujours le cas pour les BDDOO il me semble.
Je serais curieux de savoir s'il y en a qui voient ce principe en cours ?

Programmation par contrats, oui on voit ça en cours (1ère année ENSEEIHT informatique & maths appli).

POA, on n'a pas encore vu, trop récent sans doute...

[®om]

Effectivement, cela a l'air intéressant, par exemple sur ce bout de code, trouvé en bas de cette page:

Code :

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
34

public aspect LogCreditCardProcessorOperations
{ Logger logger = new StdoutLogger();

    pointcut publicOperation():
    execution(public * CreditCardProcessor.*(..));

     

    pointcut publicOperationCardAmountArgs(CreditCard card, Money amount):
    publicOperation() && args(card, amount);
    before(CreditCard card, Money amount):
    publicOperationCardAmountArgs(card, amount)
    { logOperation("Starting", thisjoin point.getSignature().toString(), card, amount);
    }

     

    after(CreditCard card, Money amount) returning:
    publicOperationCardAmountArgs(card, amount)
    { logOperation("Completing", thisjoin point.getSignature().toString(), card, amount);
    }
    after (CreditCard card, Money amount) throwing (Exception e):
    publicOperationCardAmountArgs(card, amount)
    { logOperation("Exception " + e, thisjoin point.getSignature().toString(), card, amount);
    }

     
    private void logOperation(String status, String operation, CreditCard card, Money amount)
    { logger.log(status + " " + operation + " Card: " + card + " Amount: " + amount);
    }

}

Les before() et after() sont difficiles (=pas triviaux) à implanter en java pur...

[Alec6]

Voilà deux ans je me demandais si j'utiliserai la POA

A prèsent on en voit partout et effectivement c'est super pratique.

Bonne lecture à tous.

[Hibou57]

L'AOP permet d'éviter ce parasitisme en ayant un regard sur l'exécution du compilateur. Par exemple lors d'un appel à une méthode définie le système AOP pourra exécuter un programme (avant, pendant ou après la méthode) par exemple pour un appel à logging. Ceci ce fait sans adjonction de code dans les classes de notre applie.

Si c'est ça, alors ce n'est rien de neuf... c'est exactement comme les facettes et daemons (daemon-before et daemon-after) de certains anciens langage objet (qui n'ont jamais émergé ailleurs que dans les laboratoire d'ailleur). L'idée est bonne, mais elle a manqué d'attention, ... et elle a quand même au moins 30 lustre d'âge... loin d'être une nouveauté. C'est comme AJAX : c'est un nouveau nom pour faire un nouveau concept marketing d'un truc vieux comme le monde.

[atome]

Il faudra compter avec les méthodes d'extension en C# 3, également.

[Hibou57]

Il faudra compter avec les méthodes d'extension en C# 3, également.

C'est-à-dire ?

(cette discussion dans l'ensemble, m'en inspire une autre... le temps que je rédige ça, et je ferai une autre topic)

[Alec6]

Et oui ?

Le but reste toujours de réussir à modéliser le monde.

Qu'est ce qu'il peut bien avoir de plus abstrait que l'aspect ?

Ca rappel le livre de cordon: concevoir des machines pensantes.

On a des données et le traitement regroupé en objet (logique et pratique), l'objet étant comme un sous programme fonctionnel et un système (encapsulation). L'aspect c'est une méta-programmation permettant le controle de flux (en fin surtout le controle de l'encapsulation). Et au dessus de ca il y a quoi. En relisant Cordon, peut etre que les objets aurait du etre reclassifiés en phénomène ??

[Promeneur]

Est-ce que quelqu'un sait si le tisseur aspectdng a été utilisé en production, pour un projet sérieux, ou si pour l'instant il n'est pas assez mature pour cela ?

[Davidbrcz]

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.

[Jedai]

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é,...).

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ï

[Davidbrcz]

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.

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.

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.

Débuguage, logging, invariant de classes, gestion des mutex/lock, voici à quoi je pense pouvoir utiliser les aspects

Apparemment il y a des équipes qui travaillent avec ces technologies sur des projets réels.

Aurais-tu des noms de projets (open source ou académique) pour voir comment ils utilisent la chose ?

[davcha]

Aurais tu des noms de projets (open source ou académique) pour voir comment il utilise la chose ?

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 :

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");
		}
	}
}

ou cela :

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;}
}

[Antoine_935]

C'est vrai, on a aucun contrôle dessus.

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 mienne Elle est en suspens pour l'instant, cause exams

[hydraland]

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

[sleepy2002]

Salut,

Dans mon service, nous avons eu recours à la programmation orientée aspect pour répondre à des problématiques récurrentes et verticales.

Par exemple dans le domaine financier, le calcul de la performance nette d'un fond (ou portefeuille). Il doit être déclenché par de multiples opérations (ajout/modification/suppression d'un dividende, d'une opération sur titre ou d'une valeur liquidative, sans compter la modification de certaines caractéristiques du fond ou d'autres aspects).

En résultat, nous avons tout un maillage d'aspects qui se déclenchent selon certains cas (aspect point) soit en amont (before) ou en aval (after) selon le cas.

Cela nous a apporté de la souplesse dans la programmation : centralisation du code, non intrusif, testable unitairement.

Par contre, nous voyons la POA comme un complément à la POO.

[simonlt]

Pour ma part, j'ai testé AspectJ sous Eclipse dans le but dans le contexte de recherche d'amélioration de performance. En gros, je l'ai utilisé pour injecter en début et fin de méthode du code permettant de calculer le temps d'exécution des méthodes et ainsi pister les endroits où je perdais du temps de traitement. Ce fut bien avantageux.

Cependant, j'ai galérer pour l'intégrer dans Eclipse version Ganymède.

Cette façon de travailler deviendrait très intéressant pour éviter du code d'initialisation répétitif tel l'initialisation des connecteurs sur une base de données à titre d'exemple.