EMETTEUR DE PARTICULES AS3

pegase31 Messages postés 6138 Date d'inscription dimanche 21 décembre 2003 Statut Modérateur Dernière intervention 4 septembre 2013 - 19 mai 2008 à 15:57
mousman Messages postés 23 Date d'inscription jeudi 27 janvier 2005 Statut Membre Dernière intervention 10 septembre 2008 - 10 sept. 2008 à 19:14

Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/46708-emetteur-de-particules-as3

pegase31 Messages postés 6138 Date d'inscription dimanche 21 décembre 2003 Statut Modérateur Dernière intervention 4 septembre 2013 11
19 mai 2008 à 15:57

Ces Classes échappent à ma logique personnelle ... je ne comprend pas pourquoi tu crées 2 classes qui ne produisent rien (BouleDeFeu.as et FeuDArtifice.as) et qui ne contiennent que des variables ... sans parler de la classe ParticuleDTO.as qui ne fait , pour la pluârt des fonctions) que renvoyer des valeurs par des foncitons, alors qu'il serait plus simple de rendre les variables Publiques pour y accéder.

La seule chose que je pourrais te dire c'est que l'utilisation de l'évènement ENTER_FRAME n'est plus trop de mise et il serait plus judicieux d'utiliser un objet TIMER pour éviter les lags, car plus l'animation va ramer plus elle va ramer. On en avait déjà parlé dans l'animation de fumée de volcan.

Mais peut-être que TOP30 ou d'autres personnes plus calées que moi en matière de class pourraient nous expliquer la raison d'une telle structure.

Peg'

gremlins7 Messages postés 380 Date d'inscription mardi 29 avril 2003 Statut Membre Dernière intervention 28 décembre 2009
20 mai 2008 à 19:23

Bonjour,
Je suis d'accord avec Pegase31, les classes BouleDeFeu.as et FeuDArtifice.as n'ont pas de raison d'exister...tu utilises ces classes pour configurer l'objet ParticulesDTO. C'est a dire que tu construit l'objet ParticulesDTO autrement qu'avec son constructeur propre que tu as d'ailleurs laissé vide !!!
Je te propose de le remplir de la manière suivante :

public function ParticuleDTO(Feu_Ou_Boule:String)
{
if(Feu_Ou_Boule=='Feu')
{
copier coller de FeuDArtifice.as //la tu construit les params pour FeuDArtifice
}
else
{
copier coller de BouleDeFeu.as //la tu construit les params pour BouleDeFeu
}
}

du coup tu efface ces classes qui ne servent plus a rien et tu construit avec :

var particules:ParticuleDTO=new ParticuleDTO('Feu'); par exemple ou
var particules:ParticuleDTO=new ParticuleDTO('Autre_Construction_Possible');

mousman Messages postés 23 Date d'inscription jeudi 27 janvier 2005 Statut Membre Dernière intervention 10 septembre 2008
20 mai 2008 à 22:10

ok, une explication alors sur la raison d'être de bouledefeu et feudartifice et particuleDTO:

dans cet exemple leur sens n'est pas forcément évident c'est vrai , c'est aussi à but didacticiel.
Ils sont pour là rendre plus facile l'évolution d'une application.

- gremlins
ta solution est très bien si tu n'as que ces 2 jeux de paramètres que j'ai mis en exemple,
mais si il y en a 10 ou 20 ou plus (les possibilités avec le générateur sont nombreuses) tu te retrouves avec une classe énorme remplie de if,
ce qui n'est pas vraiment dans la philosophie objet.
Dans ce cas l'héritage et le polymorphisme sont plus recommandés , même si pour être encore plus propre dans les classes qui étendent ParticuleDTO j'aurai dut utiliser les setter (les méthodes) plutôt que redéfinir les variables
ou pour aller plus loin utiliser un design pattern de type factory ou builder....

En ce qui concerne ParticuleDTO :
un DTO (Data Transfert Object) est une sorte de conteneur qui sert (qui ne sert qu') à passer un ensemble de paramètres entre deux objets. (je résume un peu)
Il ne contient que des variables définies en private et des méthodes pour les définir (c'est un bean en java), méthodes définies en public, le constructeur est toujours vide.
pourquoi :
pour réduire la dépendance entre les objets :
si je décide demain qu'un des paramètres du DTO n'est plus une variable mais le résultat d'un calcul entre deux autres paramètres du DTO,
je n'ai qu'a changer la méthode set et get de cette ancienne variable du DTO,
sans avoir à modifier tous les fla ou autres qui utilisent le générateur,
c'est un gain de temps important
le DTO permet aussi de mettre des valeurs par défaut aux paramètres et de les rendre ainsi facultatifs ce qui évite d'avoir à tout définir au niveau des variables à chaque utilisation du générateur dans un fla

Voila....
j'ai un peu survolé le sujet mais j'espère avoir été clair et avoir apporté qqchose.
le débat reste ouvert :-)

top30 Messages postés 1158 Date d'inscription vendredi 21 février 2003 Statut Membre Dernière intervention 6 août 2010
21 mai 2008 à 15:57

Le concept est fort interessant.
J'apprécie l'effort et applaudi l'argumentation des tes commentaires. Même si je ne suis pas d'accord avec, au moins ils ont le méritent d'être "soutenables".

Ta structure devrait suivre certain concept utilisé par Flash. Et te libérer des dépendances de la blibliothèque. Tu n'est pas loin d'arriver. Je vais essayer de t'aider et de rester clair:

1/ ParticuleEmetteur.as
Se devrait appeler "ParticuleManager" (comme tu l'as fait dans le Fla). C'est elle qui devrait déterminer certain paramétres que l'objet ParticuleDTO n'a pas besoin de connaitre, comme par exemple le nombre de particule par seconde, ou le comptage de création d'instance (compteur), etc...

var partManager :ParticuleManager= new ParticuleManager( AbstractParticule );
// De plus ce n'est pas nécessaire qu'il soit un élément visuel...

La transformation des particules se devrait faire à travers un object "ParticuleMatrix", simple à faire : retirer une partie de ton code de "ParticuleManager" pour un faire un "ParticuleMatrix", qui pourrait modifier à souhait toute particlue passer en paramètre.

partManager.matrix= new ParticuleMatrix() ;
partManager.matrix.transform(particule) ;

2/ ParticuleDTO.as
Se devrait réellement s'appeler "ParticuleData" car elle ne transfert pas de données, mais simplement les stock. De plus un des gros inconvénient de l'utilisation tes classes est ICI dans la classe ParticuleDTO, LE NOM DES VARIABLES:
- Si la propriété "g" est la gravité, pourquoi ne pas la nommer "gravity" ???
- Si "ss" est suivreSouris pourquoi ne pas la nommer "followMouse" ???
- Si "dx1" et "dx2" ont des décalages pour ne pas en faire une array "offsetX" ????

3/ BouleDeFeu.as
Ne devraitpas faire partie de ton package "com.mousman.flash9.fx.particules.BouleDeFeu", mais d'un sous package "com.mousman.flash9.PRESETS.particules.BouleDeFeu". Il ne dépend pas de ton package car c'est en fait un presetting "ParticuleData".

Dans l'absolu une particule ne devrait pas être non plus une classe "visuelle" type Sprite ou MovieClip. Mais une classe belle et bien indépendante capable de transformer tout object "DisplayObject" : tes modifications étant enièrement supportées par la classe "DisplayObject" ( x, y, scaleX, scaleY, alpha, rotation, colorTransform, etc...).
Ces transformations se faisant à travers une classe "ParticuleView".

var view :ParticuleView= ne ParticuleView(myDisplayObject) ;
view.transform(TransformMatrix);
// Te liberant ainsi de toute obligation avec la bibliotheque...

Donc pour résumer:

ParticuleManager
// Créer et gére les particules

ParticuleData
// Contient les données initiales des particule

ParticuleMatrix
// Contients les routines de transformation

ParticuleView
// Transformant tout object visuel.

Je n'ai mis que 9 car je trouves cela un peu "compliqué" pour ce que c'est rèllement dans l'etat actuel das choses. Si tu étais ammener à changer tes classes, je suis interessé par en suivre le cours...
Espérant t'avoir aider un peu.

gremlins7 Messages postés 380 Date d'inscription mardi 29 avril 2003 Statut Membre Dernière intervention 28 décembre 2009
22 mai 2008 à 13:38

Non pas de degradé alpha, mais je suis en train de traquer les fonctions gourmandes en placant des compteurs partout...j'ai quand même le sentiment qu'a un moment donné cette methode bouffe de la ressource...
Dès que j'ai fini je posterai le code, j'espère que Top30 pourra y jeter un oeil...