Come capire il modello di progettazione per questa particolare soluzione?

Questo problema descritto mi ricorda Modelli di adattatori e facciate: essere adattivi .

Durante la lettura della tua domanda, ho anche ricordato un famoso vecchio detto divertente:

If it walks like a duck and quacks like a duck, then it must be a turkey wrapped with a duck adapter...

Potresti ottenere una spiegazione dettagliata dal seguente libro: Head First design Patterns

Inoltre, ci sono i SOLID principi e Principio di sostituzione di Liskov è uno di questi. Affronta anche questo problema con un sapore diverso.

If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction

È un errore utilizzare l'ereditarietà con le classi e le interfacce Legs . (Ma se il tuo insegnante / capo insiste sul fatto che ... devi probabilmente arrenderti.)

Il tuo design funziona abbastanza bene per i requisiti che hai elencato. Ma supponiamo che esista un Horse che può sia run che jump . Come lo implementate?

Suggerisco che WalkingLegs , RunningLegs e JumpingLegs siano tutte classi separate senza ereditarietà. Il Tiger avrebbe WalkingLegs e RunningLegs , il Kangaroo avrebbe WalkingLegs e JumpingLegs , e il Horse avrebbe tutti e tre.

Il suggerimento sopra confonde la metafora Legs . Ciò che stiamo realmente modellando è il comportamento, non i tipi di gambe .

L'uso delle classi per rappresentare un comportamento fa parte del modello di strategia. Nel modello di strategia, i comportamenti hanno diverse implementazioni (in questo esempio, diversi strumenti di camminare, saltare, ecc.)

Per me, sembra un caso di brutta astrazione. Le classi base sono per il comportamento di astrazione uguale per tutti i bambini attesi. Quale è sbagliato nel tuo esempio. Nel tuo caso o vuoi Move metodo virtuale, e poi sostituirlo in animali concreti. O vuoi i metodi Jump e Run , ma poi non c'è niente di comune tra di loro, quindi astrarre via non ha senso.

E c'è una regola che mi piace quando faccio questo:

Abstractions should always be seen from point of who will use those abstractions. Not from the inside of the implementation.

Se stai scrivendo qualche astrazione e non hai scritto codice che userà questa astrazione, allora stai facendo qualcosa di sbagliato.

Probabilmente implementerei qualcosa in questo senso:

public abstract class Animal: ILegs
{
    public virtual void Walk(){/*Base logic for walking*/}
}

public interface ILegs
{
    void Walk();
}

public interface IJumpingLegs
{
    void Jump();
}

public interface IRunningLegs
{
    void Run();
}

public class Kangeroo : Animal, IJumpingLegs
{
    public void Jump()
    {
        //Logic for Jumping
    }
}

public class Tiger : Animal, IRunningLegs
{
    public void Run()
    {
        //Logic for Jumping
    }
}


//Custom Implementation
public class OtherAnimal : Animal
{
    public override void Walk() { /*Custom how I walk*/ }
}

Quando ho installato i miei oggetti, userei

OtherAnimal a = new OtherAnimal();
a.Walk(); //Custom override logic fro OtherAnimal class

Tiger t = new Tiger();
t.Run();  //Custom Run logic
t.Walk(); //Logic from Animal abstract class

Ogni classe Tiger / Kangeroo implementa solo l'interfaccia necessaria per ogni classe e non eredita alcuna logica inutile e non infrange il Principio di sostituzione di Liskov menzionato da @Yusubov.

La classe Tiger / Kangeroo usa anche la logica base Walk () della classe abstract Animal e ha l'opzione, se necessario, di sovrascriverla che si trova nella classe OtherAnimal.

Semplicemente non implementare una classe di pesci o simili estendendo l'animale. I pesci non camminano o hanno le gambe !!