Partage

Constructeur de conversion

Classes dans differents projets

17 août 2018 à 17:17:59

Bonjour a tous , 

Dans le cadre de mon travail , j'ai un coequipier qui doit implementer des constructeur de conversion entre differente classe representant des points ( 2d et 3d ). Cependant on se retrouve avec un probleme de redefinition circulaire lorsque nous incluont un fichier dans un autre qui inclu ce meme fichier.

Mon coequipier a suggerer les forward declaration ... mais comme les classes sont dans des projets differents je ne crois pas que cela fonctionne ( le projet declarant une classe de meme nom mais differente du second projet ) .. 

Est-ce faisable les constructeurs de conversion entre les classes de differents projets ?

-
Edité par Zérotisme 17 août 2018 à 17:20:49

Vous êtes demandeur d'emploi ?
Sans diplôme post-bac ?

Devenez Développeur web junior

Je postule
Formation
en ligne
Financée
à 100%
17 août 2018 à 17:37:09

Oui, mais c'est pas logique.

Il doit avoir une certaine logique dans le découpage des projets, au moins en terme hiérarchique, quel projet/module utilise les fonctionnalités de tel autre module. Les liens bidirectionnels entre module, ça pue.

Donnez petit exemple pour voir comment on peut restructurer votre plat de spaghetti pour qu'il soit plus digeste.

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
17 août 2018 à 17:49:09

bacelar a écrit:

Oui, mais c'est pas logique.

Il doit avoir une certaine logique dans le découpage des projets, au moins en terme hiérarchique, quel projet/module utilise les fonctionnalités de tel autre module. Les liens bidirectionnels entre module, ça pue.

Donnez petit exemple pour voir comment on peut restructurer votre plat de spaghetti pour qu'il soit plus digeste.


Merci de la reponse.

C'est un projet qui date de +- 15 ans et il n'est pas possible d'unifier le type de point utiliser sans briser l'API complete c\est pourquoi nous avons recu la demande de faire des constructeur de conversion.

L'Architecture concernant les point n'est pas tres compliquer , ils ne sont que dans des projets differents.
- Projet 1 -> PointBase
- Projet 2 -> Point2D
- Projet 3 -> AnotherPoint

Malheureusement je ne connais pas larchitecture plus en profondeur c'est ma premiere semaine dans cette boite.

EDIT :: Comme le probleme est du a la bidirectionnalite ( bon apres le probleme d architecture ... ) nous avons penser prendre un des points qui se construirais a partir de tous les autres points , donc dans une seule direction. Avec une fonction static de conversion du point de base vers les autres pour garder une compatibilite ...

-
Edité par Zérotisme 17 août 2018 à 17:55:43

17 août 2018 à 18:11:07

Le passage point 2D <-> 3D juste par conversion me choque. 3D vers 2D, il faut projeter, et dans l'autre sens c'est un chouilla plus compliqué encore.

Est-ce vous sûr qu'il est pertinent de vouloir tout unifier? Définissez plutôt des fonctions libres qui permettent de passer de l'un à l'autre, moyennant informations de projection.

C++: Blog|FAQ C++ dvpz|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS| Bons livres sur le C++| PS: Je ne réponds pas aux questions techniques par MP.
17 août 2018 à 18:15:49

Je suppose que tout ce bordel de projets est compilé avec le même compilateur, la même version, les mêmes options de compilations et les mêmes constantes de compilation (sinon, vous êtes bien dans la mer..).

Les API entre les projets, c'est des API C ou C++ ?

J'espère que PointBase/Point2D, c'est juste des exemples à la con, car c'est un exemple pathologique de mauvaise conception de hiérarchie de classe.

C'est quoi le lien que vous voulez instaurer entre les différents Projet ?

Projet1, Projet2, Projet3 sont indépendants et vous voulez un Projet4 qui utilise les résultats de compilation des 3 autres projets, ou vous voulez lier ces 3 projets ?

Avant de penser au découpage qui a été fait, pouvez-vous nous donner un truc à la UML qui donne les classes, leur arbre héritage et leur composition en terme de champ ? (les infos des .h quoi)

Si vous n'avez pas ces informations avant de concevoir une solution, vous allez directement dans le mur.

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
17 août 2018 à 18:16:02

lmghs a écrit:

Le passage point 2D <-> 3D juste par conversion me choque. 3D vers 2D, il faut projeter, et dans l'autre sens c'est un chouilla plus compliqué encore.

Est-ce vous sûr qu'il est pertinent de vouloir tout unifier? Définissez plutôt des fonctions libres qui permettent de passer de l'un à l'autre, moyennant informations de projection.


Le but n'est pas de convertir un point 2d en 3d ou l'inverse. Mais de tous les points a tous les autres ( je sais c'est de pire en pire :D ). Je ne suis pas sur a propos de la conversion d'une dimension a l'autre ( disons simplement que nous devons convertir les points 2d en d'autre point 2d et idem pour les points 3d . )

Nous avons penser deja aux fonctions libre. Suggestion non ecartee mais comme la demande ( qui vient d'un autre bureau aa 10 000 km lol ) c'est d'offrir des constructeur de conversion nous tentons de trouver la solution a cette approche avant d'aller vers les fonctions libres ou faire une conversion uni-directionnelle.
17 août 2018 à 18:25:23

Montrez votre code actuellement et les messages d'erreurs correspondants.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
17 août 2018 à 18:25:41

Ce qui ne gêne, c'est que de passer d'un type de point à l'autre n'a pas de sens, et cela ne sera probablement jamais utilisé.

Après, nettoyer un projet qui jongle entre 15000 implémentations différentes de points 2D, pour n'en garder qu'une, ça peut devenir pertinent.

PS: au moins, je n'ai pas vu passer d'héritage public dans la description, à priori vous passez donc à côté de cette faute de conception -- démonstration de la faute de conception dans Effective Java de Joshua Bloch.

C++: Blog|FAQ C++ dvpz|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS| Bons livres sur le C++| PS: Je ne réponds pas aux questions techniques par MP.
17 août 2018 à 18:28:12

bacelar a écrit:

Je suppose que tout ce bordel de projets est compilé avec le même compilateur, la même version, les mêmes options de compilations et les mêmes constantes de compilation (sinon, vous êtes bien dans la mer..).

Les API entre les projets, c'est des API C ou C++ ?

J'espère que PointBase/Point2D, c'est juste des exemples à la con, car c'est un exemple pathologique de mauvaise conception de hiérarchie de classe.

C'est quoi le lien que vous voulez instaurer entre les différents Projet ?

Projet1, Projet2, Projet3 sont indépendants et vous voulez un Projet4 qui utilise les résultats de compilation des 3 autres projets, ou vous voulez lier ces 3 projets ?

Avant de penser au découpage qui a été fait, pouvez-vous nous donner un truc à la UML qui donne les classes, leur arbre héritage et leur composition en terme de champ ? (les infos des .h quoi)

Si vous n'avez pas ces informations avant de concevoir une solution, vous allez directement dans le mur.

1 - Memes options etc selon la plateforme ( nous travaillons sur du hardware d'avion et bateau ).
2 - C++99 ( avec des printf_s lol )
3 - C'etait des exemples a la con mais qui reflete la realite
4 - Les projets sont independant ( il y a une dizaine de points dans une dizaine de projets differents .. ) . Nous avons un autre projet qui utilise ces projets , dont les points.
5 - Le but est : a partir des projets 'utilisateur' nous voulons pouvoir convertir les points des projets inferieurs , mais la demande faite demande des constructeur de conversion explicit ..

bacelar a écrit:

Montrez votre code actuellement et les messages d'erreurs correspondants.


On peut facilement resumer en 

Projet 1 - Point

class Point {
    // convert to projet2.Point2d
}


Projet 2 - Point2d

class Point2d {
   // convert to projet1.Point
}


L'erreur a cause des includes : .... already defined.

lmghs a écrit:

Ce qui ne gêne, c'est que de passer d'un type de point à l'autre n'a pas de sens, et cela ne sera probablement jamais utilisé.

Je suis de l'equipe de dev du framework. La demande a ete fait par l'equie de dev des jeux , donc j'imagine que c'est pour s'en servir ?

-
Edité par Zérotisme 17 août 2018 à 18:34:15

17 août 2018 à 18:50:40

Si les projets vous appartiennent, condition sine qua non pour modifier les constructeurs, alors profitez-en pour nettoyer en définissant une unique classe point 2D qui sera utilisée par tous les autres projets, quitte à offrir des `using` locaux pour faciliter la migration. S'il ne vous appartiennent pas, alors pour ne pourrez pas rajouter de constructeurs...

Je ne doute pas qu'il y a un besoin d'uniformiser 150 classes de points 2D. De là à ce que ceux qui spécifient le besoin croient que tant qu'ils y sont autant se mélanger allègrement avec les autres types de points (3D...), cela ne me surprendrait pas qu'il y ait eu juste une généralisation hâtive par un esprit informaticien (*) pensant qu'il suffit de passer Z à 0...

(*) les scientifiques à qui je donne des formations -- et qui bossent dans le domaine de l'imagerie spatiale -- ne font pas ce raccourci

Pas le temps d'élaborer -> google Matthew Wilsson shim -> http://www.synesis.com.au/resources/articles/cpp/shims.pdf
Autre approche: std::string_view, gsl::span... Mais là, les objets coûtent bien plus cher au départ.

C++: Blog|FAQ C++ dvpz|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS| Bons livres sur le C++| PS: Je ne réponds pas aux questions techniques par MP.
17 août 2018 à 18:56:31

lmghs a écrit:

Si les projets vous appartiennent, condition sine qua non pour modifier les constructeurs, alors profitez-en pour nettoyer en définissant une unique classe point 2D qui sera utilisée par tous les autres projets, quitte à offrir des `using` locaux pour faciliter la migration. S'il ne vous appartiennent pas, alors pour ne pourrez pas rajouter de constructeurs...

Je ne doute pas qu'il y a un besoin d'uniformiser 150 classes de points 2D. De là à ce que ceux qui spécifient le besoin croient que tant qu'ils y sont autant se mélanger allègrement avec les autres types de points (3D...), cela ne me surprendrait pas qu'il y ait eu juste une généralisation hâtive par un esprit informaticien (*) pensant qu'il suffit de passer Z à 0...

(*) les scientifiques à qui je donne des formations -- et qui bossent dans le domaine de l'imagerie spatiale -- ne font pas ce raccourci

Pas le temps d'élaborer -> google Matthew Wilsson shim -> http://www.synesis.com.au/resources/articles/cpp/shims.pdf
Autre approche: std::string_view, gsl::span... Mais là, les objets coûtent bien plus cher au départ.


D'apres mon superieur une refonte des projet est prevu au cour de l annee mais pour l'instant entreprendre de changer tous les points pour une seule classe serait une mission suicide , nous devont donc trouver la meilleur approche pour unifier ces points.
En ce moment 2 solutions s'offrent a nous :
1 - Que des fonctions libre pour les conversion

2 - Plus proche de la demande : Offrir un constructeur de conversion pou chacun des points dans la classe de point qui est le plus utilise

3 - reussir a faire des constructeur de conversion dans chacune des classes ? ( mais ca aucune idee comment seulement que bacelar a dit que cetait possible. )

17 août 2018 à 19:03:33

Il me semble qu'il a un problème dans la conception qui vous est demandé.

(Déjà, ils devraient pas vous donner le "comment faire", mais le "que doit fournir comme service les classes du nouveau projet")

Si on fait une classe pour regrouper des classes hétérogènes, c'est surtout pour les encapsuler pour que l'utilisateur de la nouvelle classe n'est pas à connaitre le capharnaüm que constitue les "anciennes" classes.

Donc des constructeurs explicites d'objets du nouveau projet en prenant en paramètre les objets des vieux projets, ça casse direct l'encapsulation.

Si l'on considère que Projet1 et Projet2 sont des "projets inferieurs", pourquoi doivent-ils inter-opérer ???

Les "projets 'utilisateur'" doivent connaitre les "projets inferieurs" ??? Pourquoi pas juste un projet "wrapper" ?

S'ils utilisent un projet "wrapper", ils n'ont pas besoin de convertir des "points" mais juste connaitre la classe point du projet "wrapper".

>L'erreur a cause des includes : .... already defined.

Je vois 2 explications, vous avez oubliez/déconner avec les "include guard", ou vous avez des collisions de nom de classe.

Chaque "projet inférieur" est une lib, une Dll ?

Si c'est le cas et que le problème est un problème de collision de nom de classe, il faudra ruser.

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
17 août 2018 à 19:09:05

bacelar a écrit:

Il me semble qu'il a un problème dans la conception qui vous est demandé.

(Déjà, ils devraient pas vous donner le "comment faire", mais le "que doit fournir comme service les classes du nouveau projet")

Si on fait une classe pour regrouper des classes hétérogènes, c'est surtout pour les encapsuler pour que l'utilisateur de la nouvelle classe n'est pas à connaitre le capharnaüm que constitue les "anciennes" classes.

Donc des constructeurs explicites d'objets du nouveau projet en prenant en paramètre les objets des vieux projets, ça casse direct l'encapsulation.

Si l'on considère que Projet1 et Projet2 sont des "projets inferieurs", pourquoi doivent-ils inter-opérer ???

Les "projets 'utilisateur'" doivent connaitre les "projets inferieurs" ??? Pourquoi pas juste un projet "wrapper" ?

S'ils utilisent un projet "wrapper", ils n'ont pas besoin de convertir des "points" mais juste connaitre la classe point du projet "wrapper".

>L'erreur a cause des includes : .... already defined.

Je vois 2 explications, vous avez oubliez/déconner avec les "include guard", ou vous avez des collisions de nom de classe.

Chaque "projet inférieur" est une lib, une Dll ?

Si c'est le cas et que le problème est un problème de collision de nom de classe, il faudra ruser.

- include guards bien present

- nom de classes differents ( Vector2 , CBPoint , BAOPoint , ... )

- les projets inferieurs sont des libs.

- les projets inferieurs inter-oper que dans ce cas de conversion , sinon pour l'instant aucun des projets inferieurs n'a de liens avec les autres.

- Faire un wrapper ne reviens pas au meme que de prendre une des classes points les plus utiliser et offrir les constructeur de conversion ?

EDIT :: Apres discussion avec la team de gamedev , la solution qui leur plait est la conversion des points par constructeur dans la classe de point les plus utiliser ( 1 pour int , 1 pour float et 1 pour des rect(??) ) et de faire des fonctions libre pour la retro.

-
Edité par Zérotisme 17 août 2018 à 19:25:55

17 août 2018 à 19:48:10

Pour un membre d'une équipe Framework, j'ai pas l'impression que vous vous posiez les questions sous le bon angle.

Vous devez vous posez les questions sous l'angle de l'utilisateur du Framework que vous allez proposer.

Mais bon, quand on atterrit dans un nouveau contexte, c'est pas évidant d'avoir les bons réflexes et les bons interlocuteurs pour répondre à vos interrogations.

>1 - Que des fonctions libre pour les conversion

Cela va rendre l'usage de ces fonctions super complexe pour l'utilisateur qui devra jongler explicitement avec bien trop de classe trop proche les unes des autres => PEAU DE BANANE pour les utilisateurs.

>2 - ...

Si c'est un cas possiblement acceptable par l'utilisateur du Framework ou des classes, oui, c'est très envisageable.

Les inconvénients par rapport à des classes de "wrapping" dans un projet dédiés :

- Le projet X contenant cette classe ne sera plus indépendant des autres projets "inférieurs", il y aura donc 3 niveaux:

Code utilisateur du framework -> le Projet X -> les autres projets inférieurs.

- La classe sélectionnée n'est pas forcement adaptée à l'usage que les nouveaux développements veulent en faire, donc, plutôt que de prendre la "plus utilisée", je prendrais celle qui s'adapte le mieux aux développements à venir.

Mais dans un contexte où on peut sélectionner un projet X comme API des codes utilisateurs, j'ai du mal à comprendre pourquoi ne pas utiliser que ce "Projet X".

En utilisant un projet "wrapper", vous pouvez avoir plusieurs "projet X", si les classes sélectionnées comme visibles par le code utilisateur ne sont pas toutes dans le même projet, sans que le code utilisateur n'ait à connaitre chaque "projet inférieur".

3- ...

Cela rendrait toutes les librairies des projets "inférieurs" dépendantes de toutes les autres, c'est possible mais c'est complètement con et je vous ne le conseille en aucun cas (l'astuce, c'est que tant qu'il n'y a pas d'édition de lien, on peut ajouter autant de fonction qu'on veut et que le manque de l'une d'elle ne bloque pas la compilation)

Faire un projet wrapper, c'est la possibilité d'avoir une API qui colle aux besoins actuelles, qui cache l'origine d'une classe d'une classe d'un projet "inférieur", qu'on peut choisir l'implémentation la plus adaptée aux besoins actuelles dans n'importe quel projet "inférieur", qu'on peut rendre l'API cohérente, que les changements de dépendances des projets "inférieurs" (ajout, suppression, modification, patch, etc...) seront invisibles pour le code utilisateur, etc...

Pour votre message d'erreur, il faudrait le message d'erreur bien plus complet.

Mais dans les conditions que vous donnez en "2", il n'y pas d'intérêt à faire en sorte que projet1.Point et projet2.Point2D se connaisse mutuellement (le "projet X", c'est soit projet1 soit projet2)

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
17 août 2018 à 20:30:18

bacelar a écrit:

Pour un membre d'une équipe Framework, j'ai pas l'impression que vous vous posiez les questions sous le bon angle.

Vous devez vous posez les questions sous l'angle de l'utilisateur du Framework que vous allez proposer.

Mais bon, quand on atterrit dans un nouveau contexte, c'est pas évidant d'avoir les bons réflexes et les bons interlocuteurs pour répondre à vos interrogations.

>1 - Que des fonctions libre pour les conversion

Cela va rendre l'usage de ces fonctions super complexe pour l'utilisateur qui devra jongler explicitement avec bien trop de classe trop proche les unes des autres => PEAU DE BANANE pour les utilisateurs.

>2 - ...

Si c'est un cas possiblement acceptable par l'utilisateur du Framework ou des classes, oui, c'est très envisageable.

Les inconvénients par rapport à des classes de "wrapping" dans un projet dédiés :

- Le projet X contenant cette classe ne sera plus indépendant des autres projets "inférieurs", il y aura donc 3 niveaux:

Code utilisateur du framework -> le Projet X -> les autres projets inférieurs.

- La classe sélectionnée n'est pas forcement adaptée à l'usage que les nouveaux développements veulent en faire, donc, plutôt que de prendre la "plus utilisée", je prendrais celle qui s'adapte le mieux aux développements à venir.

Mais dans un contexte où on peut sélectionner un projet X comme API des codes utilisateurs, j'ai du mal à comprendre pourquoi ne pas utiliser que ce "Projet X".

En utilisant un projet "wrapper", vous pouvez avoir plusieurs "projet X", si les classes sélectionnées comme visibles par le code utilisateur ne sont pas toutes dans le même projet, sans que le code utilisateur n'ait à connaitre chaque "projet inférieur".

3- ...

Cela rendrait toutes les librairies des projets "inférieurs" dépendantes de toutes les autres, c'est possible mais c'est complètement con et je vous ne le conseille en aucun cas (l'astuce, c'est que tant qu'il n'y a pas d'édition de lien, on peut ajouter autant de fonction qu'on veut et que le manque de l'une d'elle ne bloque pas la compilation)

Faire un projet wrapper, c'est la possibilité d'avoir une API qui colle aux besoins actuelles, qui cache l'origine d'une classe d'une classe d'un projet "inférieur", qu'on peut choisir l'implémentation la plus adaptée aux besoins actuelles dans n'importe quel projet "inférieur", qu'on peut rendre l'API cohérente, que les changements de dépendances des projets "inférieurs" (ajout, suppression, modification, patch, etc...) seront invisibles pour le code utilisateur, etc...

Pour votre message d'erreur, il faudrait le message d'erreur bien plus complet.

Mais dans les conditions que vous donnez en "2", il n'y pas d'intérêt à faire en sorte que projet1.Point et projet2.Point2D se connaisse mutuellement (le "projet X", c'est soit projet1 soit projet2)


1 - et si c'etait une fonction template specialise ? ( desole pour les accents .. ) ils n'auraient qu'a en utiliser une , du genre :

Point p = Convert<Point>(Point2dVar);
Vector2 v = Convert<Vector2>(p);...


2 - concernant la question du "point le mieu adapte" si on concidere que les points sont tous de forme X,Y , ils sont tous adapte non ?

-
Edité par Zérotisme 17 août 2018 à 20:31:11

20 août 2018 à 12:26:42

1- Pour l'utilisation d'une fonction template, autant utiliser des fonctions libres "ConvertToPoint" et "ConvertToVactor2" etc... qui seront plus explicites et plus simple à implémenter.

Mais reste le problème que vous fournissez une API complètement décousue, sans cohérences.

Ne devriez-vous pas simplement concevoir une API pour les projets utilisateurs et cacher la complexité du machin dans la librairie contenant l'API et qui cacherait les autres librairies ?

2- Ok mais c'est quoi le type de X,Y, c'est quoi les plages de valeurs probables, ne cache-t-il pas une représentation en coordonnées polaires, plus simple pour le reste de la librairie les utilisant, etc...

Pourquoi ne pas concevoir cette API s'il est facile de déterminer les plus "utiles" des couches inférieurs : vous commencez par accoler toutes les plus utiles et vous cachez les transcodages à l'intérieur de son implémentation.

Vous devriez consulter les utilisateurs de votre Framework pour qu'ils expriment leurs besoins (et pas leurs solutions).

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
21 août 2018 à 14:41:36

bacelar a écrit:

1- Pour l'utilisation d'une fonction template, autant utiliser des fonctions libres "ConvertToPoint" et "ConvertToVactor2" etc... qui seront plus explicites et plus simple à implémenter.

Mais reste le problème que vous fournissez une API complètement décousue, sans cohérences.

Ne devriez-vous pas simplement concevoir une API pour les projets utilisateurs et cacher la complexité du machin dans la librairie contenant l'API et qui cacherait les autres librairies ?

2- Ok mais c'est quoi le type de X,Y, c'est quoi les plages de valeurs probables, ne cache-t-il pas une représentation en coordonnées polaires, plus simple pour le reste de la librairie les utilisant, etc...

Pourquoi ne pas concevoir cette API s'il est facile de déterminer les plus "utiles" des couches inférieurs : vous commencez par accoler toutes les plus utiles et vous cachez les transcodages à l'intérieur de son implémentation.

Vous devriez consulter les utilisateurs de votre Framework pour qu'ils expriment leurs besoins (et pas leurs solutions).


- Le besoin est d'utiliser 1 type de point ou d'avoir les fonction pour la conversion(temporaire) , par contre , tout aracher pour utiliser qu'un point  nous obligerait a porter une +- 150 jeux sur la nouvelle version du framework. Un stress qu'ils veulent s'eviter pour l'instant car nous sommes deja dans un changement majeur ( support d'une nouvelle plateforme ).

- C'est autant decousu car y'a 18 ans ils n'avaient pas de framework vraiment pour le developpement de leurs jeux ( disont plus un bundle des libs ). Chacun des programmeur de jeu ce sont donc fait un 'petit framework' utilitaire que la compagnie a d/cider de regrouper y'a +- 15 ans pour un offrir un framework plus 'complet'. Le framework c'etant developper par dessus .. c'est devenu un bordel mais des gros changement sont en cour.
21 août 2018 à 16:21:14

> Un stress qu'ils veulent s'eviter pour l'instant car nous sommes deja dans un changement majeur

Ils sont bizarre vos "décideurs", plutôt que de souffrir un seule fois, une fois pour toutes, ils aiment délicatement décoller le pansement pour bien souffrir bien longtemps.

Quitte à avoir un budget de refactoring pour une nouvelle plateforme, on y inclus normalement la suppression des dettes techniques.

Les autruches dans toute leur splendeur ? (déjà, une dette technique de ce type pendant 18 ans, c'est de l'autruche de compétitions Olympiques)

>c'est devenu un bordel mais des gros changement sont en cour.

Cool, mais vos modifications doivent aller dans le même sens.

Votre besoin n'est pas précis : "Le besoin est d'utiliser 1 type de point ou d'avoir les fonction pour la conversion(temporaire)".

Je fais ces hypothèses :

- Vous avez +- 150 projets utilisateurs du projet "framework".

- Le framework est un gloubi-boulga de classes mais qui sont autonomes des projets "utilisateurs" (les jeux).

- Les jeux utilisent des sous parties du framework de façon anarchique et la nouvelle version du framework ne doit pas impliquer de modifications dans les jeux ( compatibilité ascendante, aux moins au niveau source)

Si on prend le sujet de la classe "Point", et que chaque jeu a sa propre classe "Point" de le gloubi-boulga, c'est bien cela ?

Le framework utilise d'autres framework/librairie de plus bas niveau.

La classe "Point" utilisée par le jeu a-t-elle une incidence dans les autres framework/librairie de plus bas niveau ?

Moi, ce que je vois, c'est l'ajout d'une nouvelle plateforme donc de nouveaux framework/librairie de plus bas niveau.

Et pour éviter que ce bordel ne pollue le code utilisant les nouveaux framework/librairie de plus bas niveau, c'est d'avoir une classe "Point" pivot qui sera "comprise" par tous les frameworks/librairies de plus bas niveau (anciens et nouveaux).

Vous faites une implémentation de cette classe "Point" pivot vers les nouveaux framework/librairie de plus bas niveau.

Vous faites en sorte de faire les implémentations de "Point" pivot qui utilise les vieux machins, quitte à créer des classes intermédiaires entre la classe Pivot pour que ces classes soient comprises par les vieux machins.

A la fin, vous avez une classe "Point" pivot utilisable par tous les nouveaux projets, vous ajoutez des fonctions de conversions entre les autres classes "Point" utilisés par le clients (qui ne seront utilisé qu'en interne du Framework) => invisible plus les vieux projets clients.

Avec des extraits de codes actuels, on pourrait vous données des conseils moins théoriques.

Je ne comprends pas dans quel cas pratique il est nécessaire de faire des conversions d'une classe de Point du JEU1 vers une classe de Point du JEU2. Un exemple, SVP.

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
21 août 2018 à 17:17:58

bacelar a écrit:

> Un stress qu'ils veulent s'eviter pour l'instant car nous sommes deja dans un changement majeur

Ils sont bizarre vos "décideurs", plutôt que de souffrir un seule fois, une fois pour toutes, ils aiment délicatement décoller le pansement pour bien souffrir bien longtemps.

Quitte à avoir un budget de refactoring pour une nouvelle plateforme, on y inclus normalement la suppression des dettes techniques.

Les autruches dans toute leur splendeur ? (déjà, une dette technique de ce type pendant 18 ans, c'est de l'autruche de compétitions Olympiques)

>c'est devenu un bordel mais des gros changement sont en cour.

Cool, mais vos modifications doivent aller dans le même sens.

Votre besoin n'est pas précis : "Le besoin est d'utiliser 1 type de point ou d'avoir les fonction pour la conversion(temporaire)".

Je fais ces hypothèses :

- Vous avez +- 150 projets utilisateurs du projet "framework".

- Le framework est un gloubi-boulga de classes mais qui sont autonomes des projets "utilisateurs" (les jeux).

- Les jeux utilisent des sous parties du framework de façon anarchique et la nouvelle version du framework ne doit pas impliquer de modifications dans les jeux ( compatibilité ascendante, aux moins au niveau source)

Si on prend le sujet de la classe "Point", et que chaque jeu a sa propre classe "Point" de le gloubi-boulga, c'est bien cela ?

Le framework utilise d'autres framework/librairie de plus bas niveau.

La classe "Point" utilisée par le jeu a-t-elle une incidence dans les autres framework/librairie de plus bas niveau ?

Moi, ce que je vois, c'est l'ajout d'une nouvelle plateforme donc de nouveaux framework/librairie de plus bas niveau.

Et pour éviter que ce bordel ne pollue le code utilisant les nouveaux framework/librairie de plus bas niveau, c'est d'avoir une classe "Point" pivot qui sera "comprise" par tous les frameworks/librairies de plus bas niveau (anciens et nouveaux).

Vous faites une implémentation de cette classe "Point" pivot vers les nouveaux framework/librairie de plus bas niveau.

Vous faites en sorte de faire les implémentations de "Point" pivot qui utilise les vieux machins, quitte à créer des classes intermédiaires entre la classe Pivot pour que ces classes soient comprises par les vieux machins.

A la fin, vous avez une classe "Point" pivot utilisable par tous les nouveaux projets, vous ajoutez des fonctions de conversions entre les autres classes "Point" utilisés par le clients (qui ne seront utilisé qu'en interne du Framework) => invisible plus les vieux projets clients.

Avec des extraits de codes actuels, on pourrait vous données des conseils moins théoriques.

Je ne comprends pas dans quel cas pratique il est nécessaire de faire des conversions d'une classe de Point du JEU1 vers une classe de Point du JEU2. Un exemple, SVP.

Je sais je sais cest un bordel ^^
Pour les nouveaux jeux ca va ils utilisent maintenant qu'un seul point. C'est le portage des ancients jeux qui pose probleme

21 août 2018 à 17:48:22

>C'est le portage des ancients jeux qui pose probleme

Je croyais qu'il fallait pas trop bouger l'architecture.

Des autruches schizophrènes ?

Faire en sorte que les anciens jeux utilisent toujours leurs anciennes classes.

Il faut "juste" changer l'implémentation des anciennes classes pour qu'elles utilisent d'autres classes, interne, du framework, pour faire le boulot.

Je ne vous conseille pas de tenter de faire entrer l'implémentation de ces classes à partir de la nouvelle classe, car cela transformerait cette nouvelle classe en dépotoirs de toutes les erreurs de conceptions des anciennes classes (une horreur).

Votre approche "bijective" classe à classe est bien trop rigide. Si cette rigidité fonctionne, un simple "#define vielleClasse NouvelleClasse" aurait fait le taf.

On va faire du concret, donnes le code de la nouvelle classe Point et une des vielles classes "Point".

Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.

Constructeur de conversion

× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
  • Editeur
  • Markdown