Ereditarietà vs "specifica" per campi

1

Attualmente sto leggendo "Testa i primi schemi di progettazione" e ho già alcune domande sul primo capitolo del libro. Questo capitolo introduce il principio di progettazione "preferisci la composizione sull'ereditarietà", spiegando il "modello strategico". La mia domanda non riguarda il modello, ma piuttosto una decisione di progettazione più basilare in uno degli esempi:

Esiste una classe Duck astratta, da cui eredita una mano piena di altre classi duck (ad esempio "Rubber-" o "Redhead-Duck"). Tutte queste anatre hanno un metodo display e quack . Il metodo display è ciò che dovrebbe essere diverso in ogni classe speciale di anatra (perché ogni anatra ha un aspetto diverso, come dice il libro).

abstract class Duck
{
    public void display();
    public void quack()
    {
        //Quack here
    }
}

class RubberDuck extends Duck
{
    @Override
    public void display()
    {
        //Display a 'Rubber-Duck'
    }
}

class RedheadDuck extends Duck
{
    @Override
    public void display()
    {
        //Display a 'Redhead-Duck'
    }
}

Ma la mia domanda è: non avrebbe molto più senso avere un campo all'interno di una classe Duck (non astratta), che contenga le informazioni di visualizzazione (un'immagine o un modello 3D per esempio) piuttosto che ereditare da una lezione di anatra astratta?

class Duck
{
    private String duckName;
    private Picture duckPicture;

    public Duck(String name, Picture picture)
    {
        this.duckName = name;
        this.duckPicture = picture;
    }

    public void quack()
    {
        //Quack here
    }
    public void display()
    {
        //Show duck here, according to the 'duckPicture' field
    }

    //More methods here, maybe a getter for the 'duckName' field
}

Qual è la tua opinione su questo? Ha senso avere una classe di anatra astratta ed ereditarla o preferisci la seconda soluzione?

    
posta Benjamin Rickels 06.04.2014 - 14:27
fonte

2 risposte

4

Devi capire che gli esempi sono quasi sempre semplificati a tal punto che le tecniche come l'ereditarietà sembrano un eccesso.

Se il codice del mondo reale fosse di una complessità simile a quella della Duck gerarchia, con ogni classe che differisce solo in quale immagine / testo essi mostrano, allora avresti un caso.

Ma in realtà, il codice del mondo reale è molto più complesso, di solito con almeno una manciata di metodi che hanno implementazioni radicalmente diverse tra le classi. In tal caso, non funziona più per rilevare la variazione in alcuni campi.

    
risposta data 06.04.2014 - 15:08
fonte
1

Se si presume che l'operazione di visualizzazione invierà solo immagini rasterizzate al dispositivo di visualizzazione, allora hai ragione: una sola implementazione del metodo di visualizzazione sarebbe sufficiente.

Ma, se hai un metodo astratto per l'operazione di visualizzazione, questo metodo può anche fare alcune cose specifiche per l'implementazione come:

  • crea l'immagine di un'anatra usando l'API openGL,
  • aggiorna altri campi di un'anatra (ad esempio isDisplayed),
  • chiama Display su oggetti secondari (ad esempio DuckWing),
  • ecc.
risposta data 06.04.2014 - 15:07
fonte

Leggi altre domande sui tag