Clarification nécessaire: classes abstraites préférées aux interfaces. Raison: ils découplent le contrat de l'implémentation

Question

Utilisez des classes abstraites (MustInherit dans Visual Basic) au lieu d'interfaces pour découpler le contrat des implémentations.

Ce qui précède est de "Type design guideline" par Microsoft. Je suis un peu confus à ce sujet. J'ai toujours pensé que les interfaces découplaient le contrat de la mise en œuvre. Que signifie exactement la ligne directrice ci-dessus?

Merci

Answer 1

Les deux classes abstraites et interfaces peuvent "découpler le contrat de mise en oeuvre". Dans une classe abstraite, les méthodes peuvent être déclarées abstraites, sans implémentation, comme lorsqu'elles utilisent une interface. Pour de telles méthodes, la classe dervived doit fournir une méthode Override avec une implémentation, comme lors de l'utilisation d'une interface. La différence entre une classe abstraite et une interface est qu'une classe abstraite peut contenir certains membres qui ont une implémentation, qui serait ensuite partagée entre toutes les classes dérivées, et elle peut contenir des champs privés/protégés ("state"), ce qu'une interface ne peut évidemment pas.

Answer 2

Je pense que c'est littéralement ce qu'il dit. Si vous voulez découpler le contrat de l'implémentation, ils suggèrent d'utiliser des classes abstraites au lieu d'interfaces. La suggestion que je comprends qu'ils font est que vous utilisez des interfaces quand vous avez besoin de polymorphisme lié à des types de valeur personnalisés, ou si vous voulez un héritage multiple, ou parce qu'un type aura un grand nombre d'implémenteurs. IDisposable par exemple est souvent hérité aux côtés de plusieurs autres interfaces, et IDisposable est implémenté par un très grand nombre de classes différentes, ce qui fait qu'il a du sens en tant qu'interface par leurs règles.

Si votre contrat ne va pas être mis en œuvre avec d'autres contrats, et qu'il sera mis en œuvre par 8 ou 10 membres différents, alors une classe abstraite est logique par la façon dont je lis ceci.

Answer 3

Les interfaces découplent les contrats de la mise en œuvre. Les directives de définition de type que vous citez ne signifient pas que les interfaces sont mauvaises pour découpler les contrats de la mise en œuvre - ce qui signifie que les interfaces ont des restrictions supplémentaires que les classes abstraites n'ont pas, donc si vous avez le choix, vers la définition de classes abstraites lorsque vous souhaitez définir un contrat sans implémentation au lieu de définir automatiquement une interface. Lors de la conception d'un contrat pour une utilisation dans une application, ce conseil est probablement juste. Toutefois, les interfaces présentent un avantage certain si le contrat est utilisé en dehors de votre application, par exemple des appels hors processus via COM ou .NET Remoting ou dans différentes langues (en dehors de .NET). Lorsque vous avez besoin d'une isolation absolue et d'une indépendance d'implémentation, les interfaces sont meilleures que les classes abstraites. Pour plus de commodité et de flexibilité à long terme au sein de votre application (et lorsque l'isolation absolue des interfaces n'est pas requise), les directives recommandent que vous puissiez utiliser des classes abstraites au lieu d'interfaces. Le libellé des lignes directrices reflète en partie le fait que les utilisateurs ont tendance à abuser des interfaces, ce qui peut entraîner un encombrement inutile et un code de mise en œuvre redondant.