Hello :) Comme tu dis.. il y a 1000 et 1 manières de faire un player c'est clair :)
Perso avec IoC et player en couches simples .. propagation des événements simples et c'est tout :) Exemple : http://www.jobinlive.com/givenchy/ Avec en IoC et mise en place des éléments au runtime : config simple externe : http://www.jobinlive.com/givenchy/config/config.eden les vues (video, buttons, progressbar etc...) : http://www.jobinlive.com/givenchy/context/display/video.eden les connexions et streams en couches simples avec une classe NetStreamExpert spécialisée pour controller le flux vidéo séparément des vues (pas besoin des vues pour controller le flux... ) http://www.jobinlive.com/givenchy/context/net/stream.eden Des simples controller/EventListener (pas de MVC ici) : http://www.jobinlive.com/givenchy/context/application/controller.eden Chaque classe implément EventListener (W3C) et en fonction des événements diffusés par les boutons, etc... l'application fait ce qu'il faut de façon simple et efficace. Chaque action à son propre module indépendant sans prise de tête. PS : et j'intègre même le tracking GAForFlash en même temps dans l'application avec un simple fichier : http://www.jobinlive.com/givenchy/context/net/ga.eden Bref... quand on maitrise le principe d'hollywood et la programmation en couche et les events W3C de façon simple... pas compliqué et impossible de faire du code dans tous les sens pour rien :) EKA+ :) Le 31 décembre 2008 00:33, zwetan <[email protected]> a écrit : > > 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 -~----------~----~----~----~------~----~------~--~---
