salut et bonnes fetes aussi
alors d'abord parlons un peu de POO avant de
définir si on va forcément utiliser des events
qlqs principes:
- la black box
on ne sait pas ce qui se passe à l'interieur
- les messages (au sens tres general)
- une black box communique avec une autre black box
via des messages
en allant un peu plus dans le detail
disons que la black box c'est l'instance d'une class
dont on ne connait pas l'implémentation interne
mais dont on connait les propriétés publiques
la black box A peut appeller les props publiques de la black box B
et vise versa
c'est basique, ca peut marcher, mais ca cause en general le probleme
de devoir garder une ref de A dans B et une ref de B dans A
l'autre probleme, c'est que cela lie les implementations
si A change ses props publiques,
B devra changer la manière dont il appelle les props publiques de A
(et vise versa)
donc en gros on a ca
A ---> B
B ---> A
les 2 instances sont séparées
pour éviter de trop lier les instances on peut utiliser des
interfaces,
mais on peut aussi utiliser les events
le petit avantage des events, c'est que meme si l'implémentation
de la class change de bcp, tant que les events ne changent pas
on a pas a modifier la maniére dont en envoie les events
cad on a ca:
A -- event(X) --> *
B -- event(Y) --> *
le désavantage des events c'est que c'est plus lent
qu'un appel direct sur une methode, et ca c'est l'avantage
d'une interface
A -- IX --> B
B -- IY --> A
le désavantage d'une interface, c'est que meme si ca ne lie
pas directement à une implémentation de classe, cela lie
à l'interface, donc si elle (l'interface) change il faudra
changer la manière de l'appeler
donc maintenant j'explique mon point ;)
quand on a 2 instances indépendantes que l'on veut faire
communiquer par des messages, en général c'est mieux d'utiliser des
events
A <-- ??? --> B
(A ne sait pas où B se trouve et vise versa)
par contre, quand on a une instance qui contient une autre instance,
là utiliser des interfaces prends plus de sens
A
|_ B
(A sait où se trouve B, et par extension B sait que A est son parent)
bon ca, c'est pour du pure code sans UI
dans flash on peut se retrouver avec une structure moins direct pour
l'UI
skin
|_ slider
|_ button
|_ background
et par ex on pourrait vouloir que quand on click sur le background on
active le drag n drop
mais que quand on click sur le bouton on joue un son
bref, c'est là où le choix des events et du bubbling peut jouer
et par extension on peut aller jusqu'au MVC etc.
mais franchement pour un player je trouve ca too much
donc je vais proposer ca: la factory
c'est pas la silver bullet mais ca permet de tester différents wiring
et donc de connecter des instances ensemble soit par events ou
references direct,
et c'est genial pour savoir quoi depends de quoi.
Donc en gros on a 2 tas d'objets
1 tas pour la logic (les business objects comme on les appelle)
cad dans le cas d'un player c'est la logique pour le volume,
le fadein/fadeout, ce genre de truc fun
et 1 autre tas pour la construction des objets, la factory,
cad là où se trouvent tous les mots clefs "new"
pseudo code
----
public class PlayerBuilder
{
public static function createPlayer():IPlayer
{
var sound:Sound = new Sound();
var volume:Volume = new Volume( sound );
var player:IPlayer = new BasicPlayer( volume );
return player;
}
}
//ex
import misc.PlayerBuilder;
var player:IPlayer = PlayerBuilder.createPlayer();
player.mute();
player.unmute();
----
le code au dessus c'est sans l'UI
parce que on a que mute() et unmute sur le player
on a pas besoin d'avoir acces a l'instance du son, mais juste du
volume,
et le volume n'a besoin d'avoir qu'a l'instance du son
maintenant regardons ce que ca donnerait avec une UI
----
public class PlayerBuilder
{
public static function createGraphicPlayer():IGraphicPlayer
{
var sound:Sound = new Sound();
var volumeButton:VolumeButton = new VolumeButton( sound );
var player:IGraphicPlayer = new GraphicPlayer( volumeButton );
return player;
}
}
----
on garde la meme logique, le bouton de volume
n'a besoin que de connaitre la reference au son
et le player graphique n'a besoin que de connaitre
la ref au bouton de volume
qlqs links pour aider
http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/
et
http://googletesting.blogspot.com/2008/10/to-new-or-not-to-new.html
(un exemple avec guice pour un MusicPlayer)
plus haut je parlais de MVC, car en fait
les events sont utilisés pour communiquer les actions
entre les controllers et les views
mais ne pas oublier que MVC ce n'est pas le seul moyen de gerer ca
voir ce post http://groups.google.com/group/FCNG/msg/bbca6837ce6182a0
où il y a toute une liste de link pour les differents "presentation
pattern":
autonomous view, code behind, passive view, etc.
par ex:
si j'avais à faire que UN player qui ne s'emboite pas avec autre chose
j'aurais tendance à faire du code behind avec une factory
d'autres feraient tout avec du MVC
ce que j'aime bien avec le code behind c'est que ca marche pas mal
avec Flex ou Flash
on peut avoir par ex toute une UI definit en MXML
et l'heriter dans le player
mais bon il y a 1000 et 1 manières de faire, ici tout ce que je dis
c'est que les events ca peut etre overkill si une instance contient
une autre instance,
et qd on commence à avoir des instances qui s'imbriquent et qu'on veut
les faire
communiquer, la factory ca permet d'y voir assez clair
zwetan
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de
Google Groupes.
Pour transmettre des messages à ce groupe, envoyez un e-mail à
l'adresse [email protected]
Pour résilier votre abonnement à ce groupe, envoyez un e-mail à
l'adresse [email protected]
Pour afficher d'autres options, visitez ce groupe à l'adresse
http://groups.google.com/group/FCNG?hl=fr
-~----------~----~----~----~------~----~------~--~---
