Interfaces/Classes abstraites et méthodes statiques

Bonjour,

Dans un de mes projets, j'utilise différentes classes qui permettent chacune de lire un type de fichier bien précis (une pour les fichier txt, une pour les xls etc...).

Dans ces classes on retrouve systématiquement les même méthodes, dont certaines sont statiques. J'aimerais donc unifier tout ça et utiliser par exemple une interface ou une classe abstraite qui me servirait de "Template" pour l'implémentation de mes classes "filles".

Problème : les interfaces et les classes abstraites ne semblent pas permettre de forcer l'implémentation de méthodes statiques. Est-ce moi qui m'y prend mal ? Est-ce possible ?

Merci d'avance pour vos lumières.

Alexandre

Citation:

---

Envoyé par Zakapatul

Problème : les interfaces et les classes abstraites ne semblent pas permettre de forcer l'implémentation de méthodes statiques. Est-ce moi qui m'y prend mal ? Est-ce possible ?

---

Non, ce n'est pas possible. Si ces méthodes statiques sont identiques dans chaque implémentation, mets les dans la classe de base. Si elles sont différentes, elles n'ont pas de raison d'être statiques à mon avis...

Citation:

---

Envoyé par Zakapatul

[...]Problème : les interfaces et les classes abstraites ne semblent pas permettre de forcer l'implémentation de méthodes statiques. Est-ce moi qui m'y prend mal ? Est-ce possible ?
[...]

---

Je vous confirme : c'est effectivement un problème de votre conception objet ; interfaces et classes abstraites sont "conçues" (dans le langage) pour introduire des contrats (et/ou des implémentations partielles, dans le cas des classes abstraites) qui impliquent des (re-)définitions de membres d'instance (et non pas des membres statiques), que ce soit des méthodes ou des propriétés, dans les classes dérivées.

Revoyez donc votre diagramme de classes / votre conception pour faire de vos méthodes statiques des méthodes d'instance.

En outre, ce faisant, il est probable que vous ayez besoin de suivre (entre autres ?) les design patterns "factory" (et/ou "abstract factory" ) et/ou singleton.

La consultation des FAQs, forums, et tutoriels "Conception" vous aidera certainement.

'HTH

La solution par la pratique :
Ninject

Tu trouveras là des exemples d'interfaces fluentes qui devrait mieux correspondre à ce que tu souhaites faire.

En tous cas :

Option 1; tu définis une classe abstraite ou non
Cette classe contient des membre virtuels
Chaque implémentation doit redéfinir les méthodes; donc non probant pour ton cas

Option 2; tu définis une interface de propriétés et de méthodes communes à chaque traitement et tu les implémentes dans des classes qui spécialiseront les traitements
C'est effectivement le mieux et le plus cohérent

Options 3;
Option 2 +
Wrapper les appels au travers d'un conteneur type Ninject de tel façon que ton point d'entrée soit un objet exploité par son interface.
C'est là que tu auras le fonctionnement voulu.

A notre, IMHO, implémenter des interfaces sans exploiter leur généricité n'a pas vraiment beaucoup de sens.

Ahhh...Je sens qu'un jour je vais devoir me faire ce tuto sur les conteneur en .NET.

Citation:

---

Envoyé par B.AF

Option 1; tu définis une classe abstraite ou non
Cette classe contient des membre virtuels
Chaque implémentation doit redéfinir les méthodes; donc non probant pour ton cas

---

Rien ne t'oblige à redéfinir les méthodes dans chaque implémentation... D'ailleurs il me semble avoir déjà eu ce débat récemment, je sais plus si c'était avec toi

Citation:

---

Envoyé par B.AF

Ahhh...Je sens qu'un jour je vais devoir me faire ce tuto sur les conteneur en .NET.

---

Ben n'hésite pas, lâche toi ;)
Ca m'intéresserait d'en savoir plus sur le sujet

Celà dit, je ne pense pas qu'il soit nécessaire de recourir à des outils comme NInject pour régler le problème de Zakapatul... Je ne remets pas en cause l'utilité de ce genre d'outils, mais ici je pense qu'une une bonne conception objet suffirait à régler le problème.

Non, mais toute occasion est bonne pour se former à de la nouveauté non ????:mouarf:

C'est pas évident de t'aider vu la faible quantité d'informations que tu nous donnes là.
Quand on parle de conception, il y a presque autant de solutions que de développeurs 8-)

Citation:

---

Envoyé par Zakapatul

Dans ces classes on retrouve systématiquement les même méthodes, dont certaines sont statiques.

---

Que font tes méthodes statiques ?

Merci à tous pour vos explications et ces différentes solutions. Effectivement, la base de classes que je devais reprendre présentait quelques "anomalies" au niveau de la conception objet, ce qui m'empêchait donc d'utiliser des méthodes "propres" telles que les interfaces et classes abstraites.

Depuis hier j'ai donc passé un peu de temps à reprendre ces différentes classes, transformer les membres statiques en membres d'instances (plus logique pour mon cas de figure) et je peux donc désormais utiliser mon interface en toute transparence et homogénéiser ainsi mon application comme je le souhaite :king:

Encore merci à tout le monde !