Je bosse avec des technos Java eclipse qui fonctionne à base de "Publish-Subscribe", ce sont les adapters et les listners dont je parlais avant. Et c'est juste chiant, lourd, plein de bug, lent, cela a du mal pour le passage à l'échelle,... etc
Dans un outil, tu as un domaine métier qui existe et un "certain nombre" de représentation (schéma, navigateur),... De base tout est statique, et des machins sont ajoutés pour tout mettre à jour. J'aimais beaucoup le principe du jeu vidéo qui est à l'inverse : tout est mis à jour tout le temps (fonction cyclique), sauf optimisations volontaires faite dans les systèmes. Je trouvais cela super sexy.
Au lieu d'avoir plusieurs arbres parallèle avec des liaisons plus ou moins standard, on a un arbre avec un objet, et un ou plusieurs composant définissent des représentations à mettre à jour, quand l'objet métier est mis à jour. Il est facile d'imaginer un bit "dirty", pour éviter une mise à jour couteuse.
L'avantage est aussi de ne plus avoir besoin de communication entre 2 types d'objet, puisqu'ils sont ici "fusionné". L'avantage aussi d'avoir des messages-entités, est de pouvoir attacher n'importe quel composant dessus. En java, on passe son temps à poser des "instanceof" sur des EObject (je caricatures), cela paraitrait tellement facile d'utiliser des entités à la place.
[^] # Re: solutions ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E07 : cartes, données et systèmes à entités. Évalué à 2. Dernière modification le 16 décembre 2013 à 13:50.
Je bosse avec des technos Java eclipse qui fonctionne à base de "Publish-Subscribe", ce sont les adapters et les listners dont je parlais avant. Et c'est juste chiant, lourd, plein de bug, lent, cela a du mal pour le passage à l'échelle,... etc
Dans un outil, tu as un domaine métier qui existe et un "certain nombre" de représentation (schéma, navigateur),... De base tout est statique, et des machins sont ajoutés pour tout mettre à jour. J'aimais beaucoup le principe du jeu vidéo qui est à l'inverse : tout est mis à jour tout le temps (fonction cyclique), sauf optimisations volontaires faite dans les systèmes. Je trouvais cela super sexy.
Au lieu d'avoir plusieurs arbres parallèle avec des liaisons plus ou moins standard, on a un arbre avec un objet, et un ou plusieurs composant définissent des représentations à mettre à jour, quand l'objet métier est mis à jour. Il est facile d'imaginer un bit "dirty", pour éviter une mise à jour couteuse.
L'avantage est aussi de ne plus avoir besoin de communication entre 2 types d'objet, puisqu'ils sont ici "fusionné". L'avantage aussi d'avoir des messages-entités, est de pouvoir attacher n'importe quel composant dessus. En java, on passe son temps à poser des "instanceof" sur des EObject (je caricatures), cela paraitrait tellement facile d'utiliser des entités à la place.
"La première sécurité est la liberté"