Bonjour, Je suis aujourd'hui confronter à un problème. Je veux tester si un objet implémente mon interface comprenant un type générique avec un type d'une classe mère pour que les classes filles passent le test, seulement, le test est strict, c'est ce type la et pas un autre. L' exemple ci dessous sera peut-être plus parlant
public interface IEquipable<T> where T : Character
{
public T Owner { get; set; }
}
public class Character {
// Base class
}
public class Player : Character {
// Child player class
}
public class Ennemy : Character {
// Child ennemy class
}
public class EquipableItem {
[SerializeField] MonoBehaviour _object;
public void MyFunction() {
// here I want to test if my Monobehaviour is IEquipable in a generic way
if (_object is IEquipable<Character>) {
// do stuff
}
/***
But the problem is that testing if _object is IEquipable with Character is false when my Mono herit from Player
I need to test if he is IEquipable with all the child class like that :
*/
if (_object is IEquipable<Player> || _object is IEquipable<Ennemy>) {
// do stuff
}
/***
But this way if tomorrow I had a new child class that herit from Character, I need to had it to the test..
*/
}
}
Est ce que quelqu'un connait une solution à ce problème parce que la je bloque
- Edité par LorenzoCoeugniet1 31 mars 2021 à 21:48:34
C'est clairement des grosses erreurs de conceptions objet.
Avoir un comportement dynamique mais être tangué dans un imbroglio d'une hiérarchie de classe qui sera beaucoup trop profondes, c'est une erreur classique des débutants en conceptions objets.
Il existe bien des moyens pour contourner ce problème, comme le simple usage du mot clé "as" ou la reflection, mais c'est vous donnez un fusil chargé pour vous arracher le pied.
Pourquoi ce n'est pas l'objet qui sait qui peut l'utiliser ? Pourquoi seul le type compte et pas l'état interne de l'objet ? Pourquoi cela ne devrait pas évoluer avec le temps, etc...
Votre conception objet est bien trop rigide, pour pas grand-chose.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Pourquoi ce n'est pas l'objet qui sait qui peut l'utiliser ? -> Parce que c'est un MonoBehaviour, et donc qui peux être n'importe quel objet de la scène de jeu (trop rigide donc)
Pourquoi seul le type compte et pas l'état interne de l'objet ? -> Parce que certains type d'objet peuvent être équipé par certains Type de classe voilà tout
Pourquoi cela ne devrait pas évoluer avec le temps ? -> Parce qu'un ennemie ne va pas se transformer en joueur au cours du temps et qu'un objet peut-être équipé que par un certains type de character, de même cela est fixe car ça implique bien d'autre choses.
J'ai réduit au strict essentiel les classes pour comprendre l'exemple, et j'ai poser une simple question. Quel est l'intérêt de venir juger de cette manière, vous venez pas dans l'intention d'aider je ne comprend pas.
Bon, bin, si vous êtes si malin, pourquoi vous n'utilisez pas "as" à la place de "is" ?
Bonne continuation dans les affres d'une mauvaise conception.
Et dites-nous quand vous passerez à l'implémentation du multi-player, là où un ennemi SERA aussi un player.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
[C#] Tester si un objet implémente mon interface
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.