L'exemple est amusant, certes mais implementer un cache quel qu'il soit en aop, c'est de la pure folie.
Soit c'est un petit cache local sans importantce (ton exemple de factorielle), t'auras plus vite fait de cacher manuellement, ca sera clair pour tout le monde et tu risques pas de cacher quelque chose qui ne devrait pas l'etre ou inversement.
Un cache, ca vient avec des regles claires et visibles, pas en douce derriere ton dos, les repercutions et effets de bords sont trop importants pour etre glisse sous le tapis. Tu peux pas juste cacher tout en n'importe quoi au ptit bonheur la chance.
Que fais tu quand tes regles vont evoluer (et elles le feront), qu'il va falloir invalider le cache pour une raison x ou y? Tu vas commencer a rajouter des cutpoint a droite a gauche, t'etales toute ta logique de gestion du cache de partout, tout devient obscur et tu t'en sort plus.
Au lieu d'avoir un point central ou tout passes (ce qui est un peu le concept du cache), tu repartis tout ca dans le systeme, ce qui est generalement le contraire de ce que tu veux faire.
Mets moi tout cas dans une classe, injectes en une insance, ecrit un service locator ou un singleton si tu peux pas faire autrement. Plus simple, beaucoup plus robuse, infiniment plus clair et tu sais ou aller voir quand ca chie.
Aller faire un tour chez nosql (ou meme sql) derriere le dos de l'appelant sans qu'il ait aucun controle dessus ni meme le moindre moyen de savoir si ca va faire un appel reseau ou pas, c'est une tres mauvaise idee.
Ca me rappelle foutrement corba par exemple et ceux qui y sont alles en sont tous revenu en ayant mal aux fesses.
Tu fais un appel innoncent a une methode sur ton thread d'ui et paf, tu te manges 500ms de delai dans la gueule, mais pas toujours, ton interface freeze et tu passes deux jours a trouve le coupable.
Ou tu fais une utilisation en apparenence innocente de ton api et en profilant tu te rends compte que ta base mango tourne a fond les ballons et que tu passes la plupart de tes ressources dans des appels reseaux.
Tu changes ton nom de methode ou de classe, et paf 100% de cache miss en permanence.
T'ecris une autre methode qui appelle un autre objet qui en appelle un autre et tu te retrouves avec une file monstrueuse d'aspect qui s'executent et le pire c'est que t'es meme pas au courant qu'ils pourraient simplement exister, toi t'as juste vu la pointe de l'iceberg.
C'est exactement le genre de cas ou il ne faut PAS utiliser l'aop, parce que ca va te peter a la gueule dans des cas subtils et tu vas passe un temps monstrueux a trouver le probleme pour potentielleme te rendre compte que t'es baise et que tu peux pas t'en sortir sans peter qq chose.
Le concept reste interressant et bon a connaitre, mais a n'utiliser qu'avec tres grande parcimonie.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Intéressant
Posté par pasScott pasForstall . En réponse au journal Des paradigmes alternatifs. Évalué à 3.
L'exemple est amusant, certes mais implementer un cache quel qu'il soit en aop, c'est de la pure folie.
Soit c'est un petit cache local sans importantce (ton exemple de factorielle), t'auras plus vite fait de cacher manuellement, ca sera clair pour tout le monde et tu risques pas de cacher quelque chose qui ne devrait pas l'etre ou inversement.
Un cache, ca vient avec des regles claires et visibles, pas en douce derriere ton dos, les repercutions et effets de bords sont trop importants pour etre glisse sous le tapis. Tu peux pas juste cacher tout en n'importe quoi au ptit bonheur la chance.
Que fais tu quand tes regles vont evoluer (et elles le feront), qu'il va falloir invalider le cache pour une raison x ou y? Tu vas commencer a rajouter des cutpoint a droite a gauche, t'etales toute ta logique de gestion du cache de partout, tout devient obscur et tu t'en sort plus.
Au lieu d'avoir un point central ou tout passes (ce qui est un peu le concept du cache), tu repartis tout ca dans le systeme, ce qui est generalement le contraire de ce que tu veux faire.
Mets moi tout cas dans une classe, injectes en une insance, ecrit un service locator ou un singleton si tu peux pas faire autrement. Plus simple, beaucoup plus robuse, infiniment plus clair et tu sais ou aller voir quand ca chie.
Aller faire un tour chez nosql (ou meme sql) derriere le dos de l'appelant sans qu'il ait aucun controle dessus ni meme le moindre moyen de savoir si ca va faire un appel reseau ou pas, c'est une tres mauvaise idee.
Ca me rappelle foutrement corba par exemple et ceux qui y sont alles en sont tous revenu en ayant mal aux fesses.
Tu fais un appel innoncent a une methode sur ton thread d'ui et paf, tu te manges 500ms de delai dans la gueule, mais pas toujours, ton interface freeze et tu passes deux jours a trouve le coupable.
Ou tu fais une utilisation en apparenence innocente de ton api et en profilant tu te rends compte que ta base mango tourne a fond les ballons et que tu passes la plupart de tes ressources dans des appels reseaux.
Tu changes ton nom de methode ou de classe, et paf 100% de cache miss en permanence.
T'ecris une autre methode qui appelle un autre objet qui en appelle un autre et tu te retrouves avec une file monstrueuse d'aspect qui s'executent et le pire c'est que t'es meme pas au courant qu'ils pourraient simplement exister, toi t'as juste vu la pointe de l'iceberg.
C'est exactement le genre de cas ou il ne faut PAS utiliser l'aop, parce que ca va te peter a la gueule dans des cas subtils et tu vas passe un temps monstrueux a trouver le probleme pour potentielleme te rendre compte que t'es baise et que tu peux pas t'en sortir sans peter qq chose.
Le concept reste interressant et bon a connaitre, mais a n'utiliser qu'avec tres grande parcimonie.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.