Discussion :

[CUCARACHA]

Salut,

Je dois créer une bibliothèque de modules à la demande qui permettront aux clients de mon CMS d'étendre leur site web avec des fonctionnalités plus ou moins évoluées: Formulaire contact, Saisie de CV, Géolocalisation Google...

Chaque module se matérialisera sous la forme d'un web service WCF qui sera consommé par le site client.

Pour se faire, j'ai imaginé, pour les OperationContract la pyramide d'interfaces suivante:

IMod
IModSubscribable : IMod
IModSubscribableFromFrontOffice : IModSubscribable
IModSubscribableFromBackOffice : IModSubscribable

J'aimerais qu'il ne soit pas possible d'hériter de IModSubscribable (disons que j'aimerais que ce soit l'équivalent d'une classe abstraite qui permettrait la factorisation des codes communs aux Front et au Back.

Je ne sais pas s'il y a un équivalent d'abstract pour les Interfaces en C#4, j'ai cherché mais je n'ai rien trouvé...

Au pire je mettrais un commentaire, mais s'il existe un verrou, j'aimerais m'en servir.

D'avance merci

Laurent

[Invité]

J'aimerais qu'il ne soit pas possible d'hériter de IModSubscribable (disons que j'aimerais que ce soit l'équivalent d'une classe abstraite qui permettrait la factorisation des codes communs aux Front et au Back.

On ne parle pas d"héritage dans le cas des interfaces mais on parle plutôt d'implémentations d'interfaces. Ton interface propose des contrats qui sont des méthodes qui seront implémentées par des classes. Donc je ne vois pas trop l'intérêt d'empêcher l'implémentation (pas héritage) d'un interface. Un interface est fait pour être implémenté par une classe et une classe peut être "sealed" empêchant tout autre classe d'en dériver.

[tomlev]

Je ne comprends pas trop ta question... Une interface, par définition, est abstraite ; elle ne contient aucune implémentation, et tu ne peux pas en créer une instance, il faut forcément une classe qui l'implémente.

On ne parle pas d"héritage dans le cas des interfaces mais on parle plutôt d'implémentations d'interfaces.

Une interface peut aussi hériter d'une autre, et dans ce cas il s'agit bien d'héritage

[CUCARACHA]

Je suis d'accord, j'explorais cette piste car elle a du sens pour ce que je veux faire car je dois créer un guide qui permettra à des sociétés externes de développer et déployer des modules sur mon système, un peu comme dot net nuke en fait (mais en mieux je pense).

Je ne vais pas me compliquer la vie, il faut que ça reste le plus simple possible et je crois que la solution est de proposer des petits starter kit avec quelques sniplets.

Merci pour ton aide,

++

Laurent

[CUCARACHA]

Je ne comprends pas trop ta question... Une interface, par définition, est abstraite ; elle ne contient aucune implémentation, et tu ne peux pas en créer une instance, il faut forcément une classe qui l'implémente.



Une interface peut aussi hériter d'une autre, et dans ce cas il s'agit bien d'héritage

En fait, je veux que l'on puisse créer soit des modules dont la souscription est publique comme par exemple une newsletter, soit des modules dont la souscription est privée comme par exemple l'inscription d'un consultant sur dans un module de saisie de timesheets.

Donc, les deux systèmes de souscription ont des points en commun, je voulais guider les développeurs en faisant en sorte que la hiérarchie des classes suive la même que celle des interfaces. mais qu'on ne puisse pas créer une classe qui n'est que l'implémentation d'une interface de factorisation.

Je ne sais pas si c'est clair...

Quoi qu'il en soit, c'est pas vital pour mon système...

++

Laurent

[Invité]

Une interface peut aussi hériter d'une autre, et dans ce cas il s'agit bien d'héritage

héhé Un grand merci pour le rappel +1

[CUCARACHA]

Oui, d’ailleurs, j'ai indiqué les héritages dans l'exemple...

[Nathanael Marchand]

Y'a un truc que je capte pas.
Si toi tu exposes un webservice, ce service ne porte que sur une et une seule interface. Côté consommateur, il ne verra pas l'héritage.
Sauf à lui donner les dlls de contrats auquel cas tu peux marquer l'interface que tu ne veux pas qu'ils implémentent comme internal.

[CUCARACHA]

Je n'ai pas encore teste mais à priori, si tu indiques dans les interfaces sous-jacentes qu'il s'agit d'opération contract, l'interface exposée comprend les membres hérité (mais je dois vérifier).

[Nathanael Marchand]

Je n'ai pas encore teste mais à priori, si tu indiques dans les interfaces sous-jacentes qu'il s'agit d'opération contract, l'interface exposée comprend les membres hérité (mais je dois vérifier).

Euh oui ben ca c'est sur, c'est le principe de l'héritage des interfaces. Ce que je veux dire c'est que le client ne verra pas qu'il y a une interface de base et des dérivées, il verra tout "à plat".

[CUCARACHA]

Oui, c'est bien ce que je veux. Je rappelle que ces interfaces sont destinées à guider les développeurs qui voudront pondre des modules pour mon système, ça me permet d'avoir une signature commune pour chaque type de module (il n'y aura pas beaucoup de types).

En gros :
RenderFrontOfficeMain -> Retourne une chaine Html, une collection de css et une collection de JS.
RenderFrontOfficeStep
RenderFrontOfficeDialog

etc.

Je dois arriver à une structure qui me permette de gérer à peu près tous les modules sachant que ça doit rester super simple pour les développeurs.

Quoi qu'il en soit, merci à tous pour l'intérêt que vous portez à cette discussion.