Architecture / Librairie générique

Bonjour,

Je cherche à résoudre le problème d'architecture suivant. D'un côté une librairie générique qui contient à la fois une hiérarchie et des structures de classe (fonctions, types d'objets encapsulés, ...). De l'autre côté, l'implémentation de cette librairie sur un problème concret.

Librairie générique

Code:

---

1 2	IBase<IResource>[Initialize(), Run()] -> IBaseType1<IResourceType1>, IBaseType1<IResourceType2> -> ... -> IBaseType1.A.IV<IResourceType1.A.IV>

---

Implémentation

Code:

---

1 2	AbstractType1:IBaseType1<ResourceType1> ConcreteType1:AbstractType1, IBaseType1.A.IV<ResourceType1.A.IV>

---

Mon problème vient de l'organisation de la hiérarchie : je veux pouvoir implémenter un niveau hiérarchique de la structure de base, pour pouvoir par exemple faire une fonction Initialize() commune (classe AbstractType1), mais aussi avoir les fonctions spécifiques d'un sous-niveau (classe ConcreteType1). Pour ça, j'ai l'impression qu'on ne peut travailler qu'avec des interfaces dans la librairie générique.
L'architecture que j'ai implémenté ci-dessous me pose deux problèmes:

1.
Lorsque je déclare

Code:

---

1 2 3

IBase<ResourceType1> instance = new ConcreteType1(); instance.Initialize()

---

, on ne passe pas dans ConcreteType1.Initialize(), même si cette fonction est déclarée en 'new' par rapport à AbstractType1.Initialize()

2.
Avec les interfaces, je ne peux renseigner aucun code dans la librairie générique alors qu'il y a du code générique (commun à toutes les branches ou spécifiques à certaines) que j'aimerais décrire, par exemple la fonction Run() du dernier élément d'une branche.


Merci d'avance pour vos lumières !

Le problème est il bien lié a une "Librairie" et aux "génériques" ?
Ou est ce un problème d'héritage et de polymorphisme ?

Ton exemple me fait mal à la tête et aux yeux, n'est il pas simplifiable afin de reproduire le problème.

Il ne faut pas créer ton objet de la sorte :

Code:

---

ConcreteType1 instance = new ConcreteType1()

---

Sinon, je tenterai un cast sur "instance" en "ConcreteType1" afin d'utiliser le bon "Initialize".

Code:

---

((ConcreteType1) instance).Initialize()

---

Ericlm,

Merci de ta réponse.
J'ai résolu mon problème #1 d'accès à Initialize(), en fait le mot-clé 'new' n'est pas suffisant, il faut carrément utiliser 'override'. Le pourquoi du comment est expliqué ici.
Cependant, en utilisant 'override' avant de définir Initialize() dans ConcreteType1, il n'y a pas besoin de faire le cast que tu mentionnes (et qu'on essaie d'éviter justement).

Citation:

---

...the implementation of an interface method is implicitly 'final', just as if the 'sealed' and 'override' modifiers were present.
Yup, you read that right: implementing an interface method implicitly seals the method (as well as overriding it). So, unless you tell it otherwise, the first implementation of an interface ends the override chain in C#.

---

Pour le problème #2, je pense que mon architecture n'est pas la meilleure pour résoudre le problème, et c'est pour ça que je viens demander vos avis.
La formulation n'est pas géniale, j'aimerais bien dans l'idéal faire des schémas, mais je ne vois pas d'outils qui permettent de faire ça sur developpez.net.

Citation:

---

Envoyé par Luigicube

La formulation n'est pas géniale, j'aimerais bien dans l'idéal faire des schémas, mais je ne vois pas d'outils qui permettent de faire ça sur developpez.net.

---

Pour ca tu peux tout simplement utiliser Paint, Visio ou autre ensuite il suffit d'uploader ton oeuvre en tant que pièce jointe : Lire et écrire des messages

Mes talents d'artiste sont encore plus pauvres que mes talents d'écrivain, malheureusement.
Un problème que je rencontre avec l'architecture ci-dessus :

Librairie générique

Code:

---

1 2 3

IBase<E> where E:IElement {E ParameterExample {get; set; } IBaseExtension<Ext> : IBase<Ext> where Ext:IElement {}

---

Implémentation

Code:

---

1 2 3 4 5

Element : IElement ExtElement : IElement AbstractBase : IBase<Element> ConcreteBase : AbstractBase, IBaseExtension<ExtElement>

---

ConcreteBase doit implémenter ParameterExample 2 fois :
- 1 fois venant de IBase (via AbstractBase), avec comme type de retour Element
- 1 fois venant de IBaseExtension, avec comme type de retour ExtElement

Comment s'en tirer ?

Si tu as un objet polymorphe, tu devra caster l'objet afin d'utiliser la méthode lier au type que tu souhaite (sauf pour le type native de l’objet).

J'ai effectuer quelques tests, ma première réponse devrai tout de même répondre au besoin (1). Et je trouve que ta nouvelle question s'y rapporte aussi.

La plupart des problèmes que tu as viens de la façon donc tu instancie ton objet, qui devrait être fait avec la classe plutôt que l'interface.

http://stackoverflow.com/questions/7...-instantiation
http://programmers.stackexchange.com...nterfaces-in-c

Instancie normalement et tu devrait avoir beaucoup moins de problème :

Code:

---

ConcreteType1 instance = new ConcreteType1();

---

Ericlm,
Merci de tes réponses, mais je crée des interfaces justement pour manipuler des types concrets que je ne connais pas. Au final, ça marche bien, je m'étais juste trompé sur l'utilisation d'un 'new' plutôt que d'un 'override'.

Dans mon dernier message, le problème que j'expose est de pouvoir avoir un code qui compile.

En effet, AbstractBase doit implémenter ParameterExample avec comme type de retour Element (IBase).
ConcreteBase doit implémenter ParameterExample avec comme type de retour ExtElement (IExtBase). Comme il dérive de AbstractBase, il implémente déjà ParameterExample avec comme type de retour Element.

Le compilateur ne veut donc rien savoir, même si ExtElement dérive de Element et qu'ils implémentent donc tous les deux IElement.
Je veux bien faire un cast, mais je ne vois pas trop comment m'en tirer.

Je pense que ton problème est trop ardu pour moi en faite :)

Sinon la structure ressemble elle a cela ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

public interface IElement { }   public class Element : IElement { } public class ExtElement : IElement { }   public interface IBase<Element> { Element ParameterExample(); } public interface IBaseExtension<ExtElement> { ExtElement ParameterExample(); }   public class AbstractBase : IBase<Element> { Element IBase<Element>.ParameterExample() { return new Element(); } }   public class ConcreteBase : AbstractBase, IBaseExtension<ExtElement> { ExtElement IBaseExtension<ExtElement>.ParameterExample() { return new ExtElement(); } }

---

Code:

---

1 2 3

ConcreteBase cb = new ConcreteBase(); Element Ele = ((IBase<Element>)cb).ParameterExample(); ExtElement ExtEle = ((IBaseExtension<ExtElement>)cb).ParameterExample();

---

salut,

Vu que tu implementes deux fois la meme interface, le compilo aime pas trop. Ce que tu peux faire: impemter 2 foix les interfaces via l'implementation explicite et dans une des deux methode appeller la seconde.

Bon c'est pas super comme solution, mais pourquoi as-tu besoin d'implementer IBaseExtension ?

A mon avis sur la conception il y a peut etre moyend e faire plus simple.

@Eric: C'est ça, à part que j'utilise des propriétés {get; set;} plutôt que des méthodes.
Comme le mentionne mermich, le code ne compile pas dans cette situation (d'ailleurs, ton code ne doit pas compiler non plus, si ?).

@mermich : oui, il y a sûrement moyen de faire plus simple sur la conception, c'est pour ça que je viens chercher de l'aide :) Je n'ai pas compris la solution que tu proposais, est-ce que tu peux mettre un exemple en reprenant l'exemple de ericlm ?

Je pense que je vais abandonner l'idée de créer une hiérarchie qui soit parallèle dans ma bibliothèque générique (héritage successif d'interfaces génériques) et dans ma bibliothèque concrète (qui implique donc qu'une classe pouvait étendre 2 interfaces qui sont liées).

A la place, une classe de la bibliothèque concrète va juste implémenter une interface (ou une classe abstraite) de la bibliothèque générique.
Le souci, c'est que l'héritage est bien pratique pour mettre en commun des méthodes, comme Initialize() par exemple. Il faut que je trouve une solution alternative, peut-être une classe statique...

Mon code compile correctement.