Auteur Sujet: Utilisation de structures avancées du code.  (Lu 5297 fois)

0 Membres et 1 Invité sur ce sujet

Bonjour à tous.

Je me posais une petite question : Utiliser-vous des structures avancé dans vos codes ?

Par structures avancées je parle des Singletons/Factories/Builders.
Je parle pas des Interfaces, classe Abstraite et du principe d'héritages qui sont, je pense, fortement conseillé dans la programmation objet.

Tu parles de design patterns.

Je dirais que chacun a ses habitudes, parfois on en utilise sans même le savoir. Par exemple Factory et Builder, dès qu'on est structuré, sont deux patterns qui viennent naturellement.
Singleton est celui qu'on apprend en premier, et ensuite on veut en mettre de partout, et longtemps après on se rend compte que SAY MAL.

Je demande car j'ai dû refondre mon "GeoRotoZoom"(© @lx XD) suite à la refonte de Square vers Polygon (pour faire des piles de polygones et non de carrés).
Du coup, création de classe abstraite pour uniformiser tout ça (polygon et future classe de forme) et la création de builders et de factories m'a semblé nécessaire.
(Le Factory me sert uniquement à générer des Builders particuliers, lesquels me permettent d'ajouter des animation de base, rotation/zoom/déplacement,

C'est vrai aussi que pour le moment, ça fait un peu usine à gaz car toutes la chaine (du builder jusqu'au polygone) évolue sans cesse.

Popopopopop !! Halte là malheureux !

Des factories pour gérer des shapes ? Si tu t'arrêtes pas immédiatement, tu vas bientôt créer un allocateur de bits avec souscription quand l'état du bit aura changé !

Naaaaan ! Fais SIMPLE ! Un tableau de structs et tu tapes dedans comme un porc ! Et si tu lis ma réponse dans un autre post concernant les performances : tu crées un vertex buffer avec toutes tes shapes un coup et t'y touches plus jamais. Tu l'envoies à la carte avec UN SEUL draw call, et tes animations tu les fais avec le vertex shader.

Pour répondre à ta question initiale : "utilise-t-on des structures feng-shui dans les démos" je répondrai "NON !!". Dans la mesure du possible, faut éviter. Ca fait souvent que compliquer le code pour pas grand-chose.

La vraie question à se poser est "Est-ce que ça va faire diminuer la taille du code et est-ce que ça va simplifier ma tâche ?"

Si c'est pour te faire économiser 3 lignes de code mais que ça complexifie la compréhension du code alors oublie. Si t'es pas foutu de te rappeler à quoi un truc sert ou comment on s'en sert 6 mois après l'avoir codé, c'est que tu t'es mélangé les pinceaux.

Bref. Les factories, les providers, les subscribers et toutes ces fadaises ça vaut pâquerette ! La démo c'est pour se faire plaisir, pas avoir du code certifié airbus.
(surtout que c'est pas parce que t'utilises des design pas ternes que ton code est plus lisible ou mieux qu'un autre) (c'est même souvent le contraire)

Faites simple, tabernacle ! >:( (et Dieu sait que c'est difficile de faire simple !)

Ralala je savais bien que je me plantais quelque part.

Merci Patapom de m'a voir remis dans le droit chemin.
Allez, hop demain je vois pour utiliser des vertex shader à la place de ma bouillie bouffeuse de ressources ^^

Je suis assez d'accord avec Pata, mais pour une fois j'apporte ma petite contradiction :

Dans certains cas, quelques designs simples peuvent vraiment faciliter la vie du codeur.
Par exemple :

ResourceManager resMgr = new ResourceManager();
resMgr.addResource("data/scene.truc");
resMgr.addMesh("data/machin.mesh");
resMgr.addMusic("data/music.mp3");
resMgr.addTexture("data/logo.png");
resMgr.startLoading();
while(!resMgr.finishedLoading()) {
 // afficher un écran de chargement
}
// et après on peut accéder aux ressources :
Texture logo = resMgr.getTexture("data/logo.png");
// etc...

C'est quand même vachement plus simple que de tout se pogner à la mano quand même, non ?
Après je ne sais pas si on est obligé de passer par des factory/builder derrière tout ça, mais quand même un petit peu d'organisation du code ne peut pas faire de mal.

En revanche, Crocknoks je pense que quand on fait de la démo on ne s'attarde pas sur le design au bas niveau (classe shape, etc) mais uniquement au haut niveau (ressources, timeline, management des effets entre eux...). C'est d'ailleurs peut-être ce que Pata a voulu dire en fait ^^


Oui effectivement tu peux peut-être te fader un p'tit manager à un moment mais une simple liste / tableau / hashtable suffit pour héberger tes items, pas la peine d'en faire des tonnes.

Pour les ressources, ce que tu codes c'est la routine de chargement de chaque type de ressource (image, son, mesh 3D, etc.) mais tu peux toutes les charger dans une hashtable si t'en as envie hein. Ou bien leur assigner un identifiant plus simple... De toute manière faut jamais perdre de vue que ce que tu codes c'est toi qui vas l'utiliser et qu'il y a une différence entre du "beau code" et du code utilisable.

Pour mon loader de fichiers FBX j'ai une collection de nodes qui sont des arbres de sous-nodes. Tous ces nodes sont aussi collapsés dans une hashtable pour pouvoir y accéder rapidement. Bref, j'me suis pas fait chier comme on dit... Mais vaut mieux ça qu'un code que je sais plus maintenir/utiliser 6 mois après.

J'ai beau me creuser la tête, hormis ma device Direct3D qui est un singleton (big deal !) je vois aucun pattern dans mon bazar... Et curieusement, c'est le premier bazar que j'ai réussi à utiliser et avec lequel j'ai codé quelques effets ! ;D

Pareil que Patapom, je te conseille de garder l'utilisation des patterns et même de l'héritage au minimum (bon ok pas évident en Java), ou en tout cas de pas le rechercher explicitement.

Si tu fais dériver Triangle et Ligne de Forme, tu obliges Triangle et Ligne a être un sous-type de Forme pour toujours, alors que aussi bien tu peux faire deux fonctions une qui prend une Ligne et l'autre qui prend un Triangle en paramètre et t'en sortir, et il n'y aura pas de typage prématuré.

Citer
Utiliser-vous des structures avancé dans vos codes ?
Non. Mon code est très simple. Pas d'héritage, pas de design pattern, pas d'exception, presque pas de templates, même pas de table de hachage (mais tu peux en utiliser), que des tableaux. C'est en partie lié au fait que je fais de la 64k, mais pas seulement. Comme l'a dit Patapom, il faut FAIRE SIMPLE ! La chose la plus compliquée dont tu peux avoir besoin, c'est un arbre.

Réfléchis à ce que tu veux dans ta démo. Code ce dont tu as besoin. Ne pars pas sur des abstractEffectFactoryFactoryBuilder, code directement ton effet. Ensuite, tu pourras factoriser si tu vois que des choses deviennent redondantes.

Flure : c'est pas une question d'utiliser un design pattern ou non. C'est une question de faire du code propre et simple. Si c'est plus simple de faire un objet qui charge les ressources, alors il faut le faire.

Bon, je vais en prendre de la graine moi ;)



(C'est pas spécialement pour basher Java, mais c'est vrai que cette manie de complexifier le code en y ajoutant douze mille classes avec des noms buzzword est très loin de la philosophie de la demoscene. On veut du code simple qui marche !)


C'est justement parce que je ne suis pas un fervent partisan des pattern (normal je viens du C et du php4) que je pose la question.

Je suis donc plus que ravi de voir que je n'en aurais pas besoin (ou alors cas extrême).

Je me posais une petite question : Utiliser-vous des structures avancé dans vos codes ?

Par structures avancées je parle des Singletons/Factories/Builders.
Je parle pas des Interfaces, classe Abstraite et du principe d'héritages qui sont, je pense, fortement conseillé dans la programmation objet.

Ça semble très dogmatique comme question. "fortement conseillé", en vertu de quoi, selon quels critères ? Une classe abstraite peut-être déconseillée du point de vue de la performance, l'héritage peut être déconseillé du point de vue de la lisibilité ou de la taille du code... Avant d'essayer de faire rentrer des solutions au marteau parce qu'elles sont "fortement conseillées", il faut déjà avoir un problème à résoudre.

Dans notre base de code il me semble qu'on n'a rien de tout cela (même l'héritage je ne suis pas sûr qu'on en ait encore). Quant aux singletons, personnellement je préfère une bonne grosse globale qui ne cherche pas à se faire passer pour autre chose sous prétexte qu'elle a de la crème autour.


J'aime bien cette caricature de l'évolution du programmeur, que l'on trouve sous diverses formes sur le net, et qui souligne entre autres cette période où il est persuadé que les usines à gaz avec des noms pompeux sont la solution à tous ses problèmes, quels qu'ils soient. La période qui suit, c'est celle où son code devient simple, extrêmement simple.


c'est justement parce que je ne ressemble pas à cette caricature que je demandeça m'aurais fait royalement ch*** de devoir me refader des trucs inutiles comme ça.
J'ai commencé par du basic et du c donc ce genre de structures me passent un peu loin au dessus de la tête ^^