Como reutilizar código quando herança múltipla não é uma opção?

Question

Gostaria de fazer uso de alguns métodos de alguns dos meus velhas classes testadas na minha nova classe que estou construindo. Infelizmente, C # não suporta herança múltipla. Como faço para reutilização de código a partir dessas classes de idade? Eu só criá-los como objetos membro? Ou eu tenho outras opções?

Answer 1

Geralmente, usando composição em vez de herança é o caminho a seguir, sim. Se você pudesse dar um exemplo concreto do tipo de coisa que você quer dizer, que tornaria mais fácil para ajudar a encontrar a abordagem adequada no entanto:. Não é sempre a mesma

Answer 2

Usando-os como objetos de membros deve ser uma boa idéia. Então você também pode expor apenas os métodos de interesse, e adaptá-los, se necessário.

Answer 3

Você pode recriar, em seguida, como métodos de extensão quando trabalham no mesmo tipo.

public static void MyMethod( this MyType target ){}


MyType.MyMethod()

conforme descrito abaixo, se você tem uma classe que deriva de MyType ou implementos mais comuns da interface do método de extensão funciona em, a extensão funciona para aqueles.

public class MyDerived : MyType{}

MyDerived.MyMethod()

Answer 4

Tecnicamente, C # implementos múltipla Interface inheritence, mas não múltipla aplicação inheritence.

O problema com múltiplos inheritence implementação é que ela conduz a situações como o problema diamante .

Você pode simular múltiplos inheritence implementação usando a interface múltipla inheritence e composição, que é próximo ao que você descreveu como a criação de os objetos que deseja re-uso "como objetos membros". O que você não quer fazer, porém, é expor o comportamento desnecessário do seu tipo enrolada.

A seguir é um diagrama de classes mostrando o princípio básico de múltipla inheritence através de composição:

Herança múltipla http://www.freeimagehosting.net/uploads/cb219cefba.jpg

A desvantagem desta situação é que quaisquer alterações na interface IBreeper exigirá alterações em Breeper, e vice-versa correspondente.

Tomar um passo para trás embora - você precisa olhar atentamente para as razões para compondo as velhas classes. É para:

1. melhorar ou intensificar o comportamento existente. Você deve então considerar a Proxy Padrão ;

2. Criar um "balcão único" para todo o seu comportamento. Você realmente só deve estar fazendo isso, se o seu SuperFuddler coesa (isto é, todo o comportamento exposto está alinhado), caso contrário você vai estar se movendo em uma situação Deus objeto que não é propício para ser sustentável;

3. Apresente uma interface que é mais consistente com um modo de uso exigido por uma certa classe de clientes de sua SuperFuddler. Neste caso, você deve considerar o Adapter Padrão .

Answer 5

Você pode fingir muito facilmente assim:

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

Se você desenvolveu-los como um componente, usá-los não herdam deles