'lut
 
Question simple : au-delà de l'apport certain pour la documentation (puisque c'est l'objectif), est-il pertinent/crétin/inutile de surcharger une méthode juste pour pouvoir en modifier la documentation, telle qu'elle est visible par les utilisateurs d'une classe et de ses méthodes ?
 
Ex.:

 
Si, effectivement, cela n'est ni crétin/inutile, comment faire exactement la même chose avec une propriété ?
 
Parce que là, je ne vois pas, à part en faisant "bêtement":

 
Merci pour vos réponses

Merci de ta réponse.
Oui exact, si je mets this à la place de base, y'a comme un souci .
 
Sinon, j'ai effectivement total accès à la classe de base, mais je n'arrive pas à voir comment une interface va pouvoir m'aider... peux-tu m'en dire un peu plus stp ?

OK, effectivement, cela palie ma question de départ... sauf que ma BaseClass contient déjà de la logique (pour info il s'agit d'un thread simplifié, mais générique), et comme une interface ne peut contenir que des définitions de méthodes...
 
Dans l'exemple que tu me proposes, on retrouve bien la documentation attendue en tant qu'utilisateur de BaseClass, puisqu'on a du implémenté les méthodes (vu qu'on "dérive" de l'interface).
Cependant, si j'en reviens à ma SpecificClass, si on la dérive de BaseClass, on se retrouve avec la même problématique qu'au départ. Si on implémente seulement IBaseClass, on perd la logique de BaseClass.
 
...
 
Ou alors, je n'ai pas bien compris ta réponse 8)
 
Merci de ta réponse en tout cas, ça m'a - pour le moment- permis d'apprendre la forme simplifiée {get; set;} pour une propriété que je ne connaissais pas.

J'ai lu en diagonal parce que j'ai l'impression qu'on ne se comprend pas... (nda: j'ai suffisamment de background en POO pour savoir déjà tout ça).
J'ai besoin ET de BaseClass ET de SpecificClass.
 
Quand je parle de "logique perdue", je ne fais évidemment pas référence à BaseClass, puisque ma question ne se situe pas au niveau de cette classe, mais au niveau de SpecificClass, qui si elle implémente IBaseClass (BaseClass existant par ailleurs ou pas) ne peut en aucun cas récupérer la logique incluse dans BaseClass (sauf en faisant un c/c )
 
En bref:
 
Si je fais

--> j'ai :
- la doc de SpecificClass pour les méthodes ajoutées ou surchargées par rapport à BaseClass -> bien!
- la doc de BaseClass pour les méthodes non surchargées -> pas bien! puisque j'aimerais adapter la doc trop généralise de BaseClass à cette version spécialisée de BaseClass
 
Si je fais

--> j'ai :
- la doc de SpecificClass pour les méthodes implémentées contractualisées via IBaseClass (c'est-à-dire toutes...) -> bien!
- perdu l'implémentation des méthodes de BaseClass -> pas bien! il faut alors les ré-implémenter (de toute façon, elles l'ont toutes été du fait de l'interface).
 
En bref, j'en reviens à ma question 1ère afin de recentrer le problème (ne le prends pas mal Fred82 ) afin de:
- récupérer du code déjà écrit : intérêt de l'héritage et des hiérarchies de classes (au sens général, id est classes et interfaces)
- modifier uniquement la doc côté utilisateur et pas l'implémentation sans risquer de se faire ex-communier par le dieu POO

Euh, bah oui, depuis le début j'ai besoin de SpecificClass, il me semble que c'était clair.

Quant aux raisons de mon besoin en SpecificClass, à la limite ça ne change rien au pb, mais les raisons sont simples :
- J'ai déjà écrit et utilisé BaseClass (pour info c'est une classe abstraite permettant de gérer facilement des threads, utile dans le cas de process ponctuels nécessitant de tourner en tâche de fond, ex.: l'état d'un service, le contenu d'un fichier, ...)
- J'ai déjà écrit et utilisé SpecificClass (classe dérivant de BaseClass et implémentant ses méthodes abstraites, qui est spécifiquement chargée de surveiller le contenu de fichiers textes ou binaires, de type log).
 
J'ai donc pleinement accès à ses classes, et peut y faire des modifications mineures.
 
Et si, la pertinence de BaseClass et SpecificClass est non-négociable, ajouter des interfaces, ou d'autres classes est en revanche largement envisageable si nécessaire.
 
Ma volonté étant d'écrire dès que je peux des composants ré-utilisables facilement (des problématiques telles que "ce processus tourne-t-il ?" ou "ce fichier a-t-il été modifié récemment ?" sont somme toute assez courantes), j'ai donc également la volonté de faire une doc valable (lorsque j'ai mis des composants en boîte, je les mets généralement en ligne, en partage avec qui-qui-n'en-veut).
Et il faut avouer qu'avoir la doc directement en info-bulle dans un IDE, c'est vraiment super super pratique.
 
Mon pb est donc dans le spécialisation de la doc de SpecificClass, c'est donc en fait un pb somme toute courant, dans le sens où j'ai besoin de spécialiser qqch.
En l'occurrence, au-delà de la spécialisation de l'implémentation (d'où ma nécessité de BaseClass ET de SpécificClass) pour laquelle je crée donc une classe spécialisée (SpecificClass) avec des ajouts de méthodes et des surcharges de méthodes par rapport à BaseClass, il y aussi des méthodes de BaseClass, dont je ne désire pas toucher l'implémentation, mais pour lesquelles j'aimerais changer la doc.

D'où le base.UneMethode() qui ne fait que récupérer la logique de la classe de base.
 
Evidemment le code ci-dessus n'est pas complet , j'avais essayé de cerner uniquement la problématique, mais j'ai visiblement fait "trop serré"
 
Par ailleurs, utiliser une interface à la place d'une classe spécialisée me parait à l'inverse de ce qui est attendu puisqu'on passe d'une spécialisation à une généralisation - au sens POO du terme - (après, il y a peut-être des spécificités liées aux interfaces sous .Net qui m'échappent et permettraient de faire ce que je veux).
 
Bon, peut-être juste pour me permettre d'avancer, est-ce que d'après toi, ceci:

est POO-ment parlant une horreur absolue ?

OK. Je vais donc essayer de trouver le compromis qui va bien.
 
Merci de ton aide et du temps passé sur ma question