C# - Les méthodes héritées publiquement peuvent-elles être cachées (par exemple, rendues privées à la classe dérivée) ?

Question

Supposons que j'ai une BaseClass avec des méthodes publiques A et B, et que je crée une DerivedClass par héritage.

par exemple

public DerivedClass : BaseClass {}

Maintenant, je veux développer une méthode C dans la DerivedClass qui utilise A et B. Existe-t-il un moyen de remplacer les méthodes A et B par des méthodes privées dans la DerivedClass afin que seule la méthode C soit exposée à quelqu'un qui veut utiliser ma DerivedClass ?

Answer 1

Ce n'est pas possible, pourquoi ?

En C#, on vous impose que si vous héritez de méthodes publiques, vous devez les rendre publiques. Sinon, on s'attend à ce que vous ne dériviez pas de la classe en premier lieu.

Au lieu d'utiliser la relation is-a, vous devriez utiliser la relation has-a.

Les concepteurs du langage ne le permettent pas exprès pour que vous utilisiez l'héritage plus correctement.

Par exemple, on pourrait accidentellement confondre une classe Car qui dérive d'une classe Engine pour obtenir sa fonctionnalité. Mais un moteur est une fonctionnalité qui est utilisée par la voiture. Il faut donc utiliser la relation has-a. L'utilisateur de la voiture ne veut pas avoir accès à l'interface du moteur. Et la voiture elle-même ne doit pas confondre les méthodes du moteur avec les siennes. Ni les futures dérivations de la voiture.

Ils ne permettent donc pas de vous protéger des mauvaises hiérarchies d'héritage.

Que devriez-vous faire à la place ?

Vous devez plutôt implémenter des interfaces. Cela vous laisse libre d'avoir des fonctionnalités en utilisant la relation has-a.

Autres langues :

En C++, il suffit de spécifier un modificateur avant la classe de base de private, public ou protected. Cela rend tous les membres de la base qui étaient publics au niveau d'accès spécifié. Il me semble idiot que l'on ne puisse pas faire la même chose en C#.

Le code restructuré :

interface I
{
    void C();
}

class BaseClass
{
    public void A() { MessageBox.Show("A"); }
    public void B() { MessageBox.Show("B"); }
}

class Derived : I
{
    public void C()
    {
        b.A();
        b.B();
    }

    private BaseClass b;
}

Je comprends que les noms des classes ci-dessus sont un peu discutables :)

Autres suggestions :

D'autres ont suggéré de rendre A() et B() publics et de lancer des exceptions. Mais cela ne fait pas une classe conviviale pour les gens et cela n'a pas vraiment de sens.

Answer 2

Lorsque vous essayez, par exemple, d'hériter d'une List<object> et que vous voulez cacher le direct Add(object _ob) membre :

// the only way to hide
[Obsolete("This is not supported in this class.", true)]
public new void Add(object _ob)
{
    throw NotImplementedException("Don't use!!");
}

Ce n'est pas vraiment la solution la plus souhaitable, mais elle fait l'affaire. Intellisense accepte toujours, mais au moment de la compilation, vous obtenez une erreur :

error CS0619 : 'TestConsole.TestClass.Add(TestConsole.TestObject)' is obsolete : 'This is not supported in this class'.

Answer 3

Ça semble être une mauvaise idée. Liskov ne serait pas impressionné.

Si vous ne voulez pas que les consommateurs de DerivedClass puissent accéder aux méthodes DeriveClass.A() et DerivedClass.B(), je suggérerais que DerivedClass implémente une interface publique IWhateverMethodCIsAbout et que les consommateurs de DerivedClass parlent en fait à IWhateverMethodCIsAbout et ne sachent rien du tout de l'implémentation de BaseClass ou de DerivedClass.

Answer 4

Ce dont vous avez besoin, c'est de la composition, pas de l'héritage.

class Plane
{
  public Fly() { .. }
  public string GetPilot() {...}
}

Maintenant, si vous avez besoin d'un type spécial d'avion, comme celui qui a PairOfWings = 2, mais qui autrement fait tout ce qu'un avion peut faire Vous héritez de plane. Vous déclarez ainsi que votre dérivation respecte le contrat de la classe de base et peut être substituée sans sourciller partout où une classe de base est attendue. Par exemple, LogFlight(Plane) continuerait à fonctionner avec une instance de BiPlane.

Cependant, si vous avez juste besoin du comportement Fly pour un nouvel oiseau que vous voulez créer et que vous n'êtes pas prêt à supporter le contrat complet de la classe de base, vous composez plutôt. Dans ce cas, refactorez le comportement des méthodes à réutiliser dans un nouveau type Flight. Maintenant, créez et maintenez des références à cette classe à la fois dans Plane et Bird. Vous n'héritez pas car Bird ne supporte pas le contrat complet de la classe de base... ( par exemple, il ne peut pas fournir GetPilot() ).

Pour la même raison, vous ne pouvez pas réduire la visibilité des méthodes de la classe de base lorsque vous surchargez vous pouvez surcharger et rendre publique une méthode privée de base dans la dérivation, mais pas l'inverse. Par exemple, si je dérive un type d'avion "BadPlane" et que je surcharge et "cache" GetPilot() - en le rendant privé ; une méthode client LogFlight(Plane p) fonctionnera pour la plupart des avions, mais explosera pour "BadPlane" si l'implémentation de LogFlight a besoin/appelle GetPilot(). Puisque toutes les dérivations d'une classe de base sont censées être "substituables" partout où un paramètre de la classe de base est attendu, cela doit être interdit.

Answer 5

La seule façon de le faire, à ma connaissance, est d'utiliser une relation Has-A et de n'implémenter que les fonctions que vous souhaitez exposer.