Comment réutiliser du code quand l'héritage multiple n'est pas une option?

Question

Je voudrais utiliser quelques méthodes de quelques-unes de mes anciennes classes testées dans la nouvelle classe que je construis. Malheureusement, C # ne prend pas en charge l'héritage multiple. Comment puis-je réutiliser le code de ces anciennes classes? Est-ce que je les crée simplement en tant qu'objets membres? ou ai-je d'autres options?

Answer 1

En général, utiliser la composition au lieu de l'héritage est la voie à suivre, oui. Si vous pouviez donner un exemple concret du genre de chose que vous voulez dire, cela faciliterait la recherche de l’approche appropriée: ce n’est pas toujours la même chose.

Answer 2

Les utiliser comme objets membres devrait être une bonne idée. Ensuite, vous pouvez également n'exposer que les méthodes qui vous intéressent et les adapter si nécessaire.

Answer 3

Vous pouvez ensuite recréer des méthodes d'extension quand elles fonctionnent sur le même type.

public static void MyMethod( this MyType target ){}


MyType.MyMethod()

comme indiqué ci-dessous, si vous avez une classe qui dérive de MyType ou plusieurs implémentations communes de l'interface sur laquelle la méthode d'extension fonctionne, l'extension fonctionne pour celles-ci.

public class MyDerived : MyType{}

MyDerived.MyMethod()

Answer 4

Techniquement, C # implémente plusieurs héritages interface , mais pas plusieurs. mise en œuvre héritage.

Le problème de l'héritage multiple d'implémentation est qu'il conduit à des situations telles que le le problème du diamant .

Vous pouvez simuler plusieurs héritages d'implémentation à l'aide de plusieurs interfaces. l'héritage et la composition, ce qui est proche de ce que vous avez décrit comme créant les objets que vous voulez réutiliser "en tant qu'objets membres". Ce que tu ne veux pas Cependant, vous devez exposer un comportement inutile de votre type enveloppé.

Voici un diagramme de classes illustrant le principe de base de plusieurs l'héritage par la composition:

Héritage multiple http://www.freeimagehosting.net/uploads/cb219cefba.jpg

L’inconvénient est que toute modification de l’interface IBreeper nécessitera modifications correspondantes apportées à Breeper, et vice versa.

Cependant, prenez du recul - vous devez examiner attentivement les raisons de composer les anciennes classes. Est-ce à:

1. Améliorer ou renforcer le comportement existant. Vous devez ensuite examiner le Modèle de proxy ;

2. Créez un " one stop shop " pour tout votre comportement. Vous ne devriez vraiment faire cela que si votre SuperFuddler est cohésif (c'est-à-dire que tous les comportements exposés sont alignés), sinon vous passerez à un Objet Dieu situation qui ne permet pas de maintenir facilement;

3. Présentez une interface plus compatible avec un mode d'utilisation requis par une certaine classe de clients de votre SuperFuddler. Dans ce cas, vous devez considérer le modèle d'adaptateur .

Answer 5

Vous pouvez le simuler assez facilement comme ceci:

public interface IFoo {
    void DoFoo();
}

public class Foo : IFoo {
    public void DoFoo() { Console.Write("Foo"); }
}

public class Bar {
    public void DoBar() { Console.Write("Bar"); }
}

public class FooBar : IFoo, Bar {
    private IFoo baseFoo = new Foo();
    public void DoFoo() { baseFoo.DoFoo(); }
}

//...

FooBar fooBar = new FooBar();

fooBar.DoFoo();
fooBar.DoBar();

Answer 6

si vous les avez développés en tant que composant, utilisez-les, n'héritez pas d'eux