Forums Développement Multimédia

Aller au contenu

Interface et static

CODE Actionscript

6 réponses à ce sujet

#1 pierre.corbel

  • Members
  • PipPipPipPipPipPipPipPip
  • 569 messages

Posté 28 October 2008 - 14:14 PM

Cela fais plusieurs fois que j'essaye de faire des interfaces qui force l'implémentation de méthodes statiques, mais cela est impossible (il me semble que cela ne soit pas spécifque à actionscript). Pourquoi? Cela me semble pourtant utile.


#2 durss

  • Members
  • PipPipPipPipPipPipPipPip
  • 1965 messages

Posté 28 October 2008 - 20:36 PM

[Mode je suis pas trop sûr de ce que je dit, frappez moi si j'dit d'la merde =D]

Je sais pas si la question est vraiment là.

Quel est l'intérêt de méthodes statiques dans des objets transtypés?

Pour appeler une méthode statique sur une classe il faut cibler celle ci par le nom de la classe et non une instance de celle-ci.

Dans ton cas si tu as une interface c'est (j'imagine) pour avoir un typage commun sur des instances de classes différentes non?
Si c'est le cas alors de toute façon ta méthode statique sera inaccessible puisque tu tentera d'y accéder par une instance de classe.

Si après tu fais l'interface uniquement pour "forcer" l'implémentation de méthodes sur une classe ne vaut-il pas mieux une classe abstraite?

Après moi des méthodes statiques je suis pas forcément hyper fan...(c'est pourquoi faire d'ailleurs par curiosité?)
Généralement le mot clé statique me sert seulement (et donc rarement) pour les constantes (comme les types d'Events par exemples).

De plus si l'on suit la logique de l'appel aux méthodes statiques (à savoir TaClasse.mathode()) pour appeler une telle méthode sur une interface il faudrait faire un truc du genre ITonInterface.methode() ?
Sachant que ITonInterface représente pas grand chose ça risquerait pas de fonctionner icon_razz.gif.
Faudrait donc bien que tu fasse l'appel sur ton objet transtypé qui est forcément une instance de classe.

[/Mode je suis pas trop sûr de ce que je dit, frappez moi si j'dit d'la merde =D]


Je ne m'étais jamais posé la question avant (jamais eu besoin de faire ça) et c'est vrai qu'au début je me suis dit que c'était bizarre mais finalement en réfléchissant bien ça serait pas très cohérent je trouve (tout comme l'est peut-être mon explication au-dessus ^^)

#3 pierre.corbel

  • Members
  • PipPipPipPipPipPipPipPip
  • 569 messages

Posté 29 October 2008 - 15:02 PM

Je vais prendre un exemple concret
j'ai un objet de type RecycleBin dont le but et de supprimer des images et des albums. Elle a une propriété de type Class pictureAndAlbumManager.
RecycleBin appelle après pictureAndAlbumManager.deleteImage (...); ou pictureAndAlbumManager.deleteAlbum (...);

Le but de mon interface et de fournir un guide pour les développeurs qui vont interfacer mon manager avec leur système de gestion d'image.

Mon code n'est pas très propre dans le sens ou il ne génère pas d'erreur de compilation si pictureAndAlbumManager n'est du type de mon interface. Mais en même temps, les fonction deleteImage et deleteAlbum ne justifie pas plus une instanciation que la méthode Math.cos(...).


Petite parenthèse,
Je pense que l'existence d'une syntaxe du genre Class<typeDeClass> pourrais être utile surtout depuis l'arrivée de

Action Script

[Embed(source="bratwurst.jpg")]
public var imgClass:Class;
ou imgClass peut etre bitmap, font, ...

#4 durss

  • Members
  • PipPipPipPipPipPipPipPip
  • 1965 messages

Posté 29 October 2008 - 20:52 PM

ok je voit à peu près.
Là c'est plus l'utilité de l'interface qui me pose problème.

Disons que si au moins ta variable pictureAndAlbumManager était typée sur l'interface le dev saurait que la classe devant être passée doit implémenter cette interface, là non. Donc à la limite c'est une aide au dev comme tu dis, sauf que le dev ne sait pas forcément que sa classe doit implémenter l'interface :/ (ou alors j'ai râté quelque chose)
Et si tu type ta propriété sur l'interface on en revient à ce que je disais avant vers la fin.

Pour ce qui est du Math.cos() j'avais oublié que le static était pratique aussi pour tout ce qui est utilitaire pour lequel t'as pas envie de te faire chier à instancier la classe smile.gif.
Mais dans ton cas, de toute façon t'as une instance donc autant passer par celle-ci je pense.

Modifié par Durss, 29 October 2008 - 20:52 PM.


#5 dada

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 8510 messages

Posté 29 October 2008 - 21:45 PM

Salut,

Admettons que je sois un dev qui va utiliser ton package, de quelle manière je dois interfacer avec ? (désolé, pas compris) smile.gif
De ce que j'en comprend il me parait plus essentiel d'avoir une interface sur les éléments qui peuvent être supprimés que sur le Manager.

#6 pierre.corbel

  • Members
  • PipPipPipPipPipPipPipPip
  • 569 messages

Posté 30 October 2008 - 10:11 AM

Je pense que dada as raison, mon erreur as été de ne pas faire de classe métier pour Image et Album. C'est vrai que cela résout énormément de problème... Les fonctions supprimées ont plus de sens dans ses classes que dans des classes Managers fourre-tout.


#7 pierre.corbel

  • Members
  • PipPipPipPipPipPipPipPip
  • 569 messages

Posté 30 October 2008 - 10:18 AM

Comme d'habitude lorsque j'attaque un projet sans faire de diagramme de classe, j'en paye toujours le prix a un moment.



1 utilisateur(s) li(sen)t ce sujet

0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)