Ereditarietà vs proprietà aggiuntiva con valore null

Per le classi con campi opzionali, è meglio usare l'ereditarietà o una proprietà nullable? Considera questo esempio:

class Book {
    private String name;
}
class BookWithColor extends Book {
    private String color;
}

o

class Book {
    private String name;
    private String color; 
    //when this is null then it is "Book" otherwise "BookWithColor"
}

o

class Book {
    private String name;
    private Optional<String> color;
    //when isPresent() is false it is "Book" otherwise "BookWithColor"
}

Il codice in base a queste 3 opzioni sarebbe:

if (book instanceof BookWithColor) { ((BookWithColor)book).getColor(); }

o

if (book.getColor() != null) { book.getColor(); }

o

if (book.getColor().isPresent()) { book.getColor(); }

Il primo approccio mi sembra più naturale, ma forse è meno leggibile a causa della necessità di fare il casting. C'è un altro modo per raggiungere questo comportamento?

Dipende dalle circostanze. L'esempio specifico non è realistico poiché non si avrebbe una sottoclasse chiamata BookWithColorin un programma reale.

Ma in generale, una proprietà che ha senso solo per determinate sottoclassi dovrebbe esistere solo in quelle sottoclassi.

Ad esempio, se Bookha PhysicalBooke DigialBookcome discendenti, PhysicalBookpotrebbe avere una weightproprietà e DigitalBookuna sizeInKbproprietà. Ma DigitalBooknon avrà weighte viceversa. Booknon avrà nessuna proprietà, poiché una classe dovrebbe avere solo proprietà condivise da tutti i discendenti.

Un esempio migliore è guardare le lezioni da software reale. Il JSlidercomponente ha il campo majorTickSpacing. Poiché solo un cursore ha "segni di spunta", questo campo ha senso solo per i JSlidersuoi discendenti. Sarebbe molto confuso se altri componenti fratelli JButtonavessero un majorTickSpacingcampo.

Un punto importante che non sembra essere stato menzionato: nella maggior parte delle lingue, le istanze di una classe non possono cambiare di quale classe sono istanze. Quindi, se avessi un libro senza un colore e volessi aggiungere un colore, dovrai creare un nuovo oggetto se usi classi diverse. E quindi probabilmente dovresti sostituire tutti i riferimenti al vecchio oggetto con riferimenti al nuovo oggetto.

Se "libri senza colore" e "libri con colore" sono istanze della stessa classe, quindi aggiungere il colore o rimuovere il colore sarà molto meno un problema. (Se la tua interfaccia utente mostra un elenco di "libri con colore" e "libri senza colore", tale interfaccia utente dovrebbe cambiare ovviamente, ma mi aspetto che sia qualcosa che devi comunque gestire, simile a un "elenco di rosso libri "e" elenco di libri verdi ").

Pensa a un JavaBean (come il tuo Book) come a un record in un database. Le colonne opzionali sono nullquando non hanno valore, ma è perfettamente legale. Pertanto, la tua seconda opzione:

class Book {
    private String name;
    private String color; // null when not applicable
}

È il più ragionevole. ¹

Fai attenzione però a come usi la Optionalclasse. Ad esempio, non lo è Serializable, che di solito è una caratteristica di un JavaBean. Ecco alcuni consigli di Stephen Colebourne :

1. Non dichiarare alcuna variabile di istanza di tipo Optional.
2. Utilizzare nullper indicare dati facoltativi nell'ambito privato di una classe.
3. Utilizzare Optionalper getter che accedono al campo opzionale.
4. Non utilizzare Optionalin setter o costruttori.
5. Utilizzare Optionalcome tipo di ritorno per qualsiasi altro metodo di logica aziendale che abbia un risultato facoltativo.

Pertanto, all'interno della tua classe dovresti usare nullper indicare che il campo non è presente, ma quando color lascia il Book(come tipo di ritorno) dovrebbe essere racchiuso da un Optional.

return Optional.ofNullable(color); // inside the class

book.getColor().orElse("No color"); // outside the class

Ciò fornisce un design chiaro e un codice più leggibile.

¹ Se hai intenzione BookWithColordi incapsulare un'intera "classe" di libri che hanno capacità specializzate rispetto ad altri libri, allora avrebbe senso usare l'eredità.

Dovresti usare un'interfaccia (non ereditaria) o un qualche tipo di meccanico di proprietà (forse anche qualcosa che funziona come il framework di descrizione delle risorse).

Quindi neanche

interface Colored {
  Color getColor();
}
class ColoredBook extends Book implements Colored {
  ...
}

o

class PropertiesHolder {
  <T> extends Property<?>> Optional<T> getProperty( Class<T> propertyClass ) { ... }
  <V, T extends Property<V>> Optional<V> getPropertyValue( Class<T> propertyClass ) { ... }
}
interface Property<T> {
  String getName();
  T getValue();
}
class ColorProperty implements Property<Color> {
  public Color getValue() { ... }
  public String getName() { return "color"; }
}
class Book extends PropertiesHolder {
}

Chiarimento (modifica):

Semplicemente aggiungendo campi opzionali nella classe entità

Soprattutto con il wrapper opzionale (modifica: vedi la risposta di 4castle ) Penso che questo (aggiungere campi nell'entità originale) sia un modo praticabile per aggiungere nuove proprietà su piccola scala. Il problema più grande con questo approccio è che potrebbe funzionare contro un accoppiamento basso.

Immagina che la tua classe di libri sia definita in un progetto dedicato per il tuo modello di dominio. Ora aggiungi un altro progetto che utilizza il modello di dominio per eseguire un'attività speciale. Questa attività richiede una proprietà aggiuntiva nella classe del libro. O finisci con l'eredità (vedi sotto) o devi cambiare il modello di dominio comune per rendere possibile la nuova attività. In quest'ultimo caso potresti finire con un mucchio di progetti che dipendono tutti dalle loro proprietà aggiunte alla classe del libro mentre la classe del libro in un certo senso dipende da questi progetti, perché non sei in grado di capire la classe del libro senza il progetti aggiuntivi.

Perché l'ereditarietà è problematica quando si tratta di un modo per fornire proprietà aggiuntive?

Quando vedo la tua classe di esempio "Libro", penso a un oggetto di dominio che spesso finisce per avere molti campi e sottotipi opzionali. Immagina di voler aggiungere una proprietà per i libri che includono un CD. Ora ci sono quattro tipi di libri: libri, libri con colori, libri con CD, libri con colori e CD. Non è possibile descrivere questa situazione con ereditarietà in Java.

Con le interfacce aggiri questo problema. È possibile comporre facilmente le proprietà di una classe di libri specifica con interfacce. La delega e la composizione ti consentiranno di ottenere esattamente la classe che desideri. Con l'ereditarietà di solito si finiscono con alcune proprietà opzionali nella classe che sono lì solo perché una classe di pari livello ne ha bisogno.

Ulteriori letture sul perché l'eredità è spesso un'idea problematica:

Perché l'eredità è generalmente vista come una cosa negativa dai sostenitori di OOP

JavaWorld: Perché l'estensione è malvagia

Il problema con l'implementazione di una serie di interfacce per comporre una serie di proprietà

Quando usi le interfacce per l'estensione, tutto va bene purché tu ne abbia solo un piccolo set. Soprattutto quando il tuo modello a oggetti viene utilizzato ed esteso da altri sviluppatori, ad esempio nella tua azienda, la quantità di interfacce aumenterà. E alla fine si finisce per creare una nuova "interfaccia di proprietà" ufficiale che aggiunge un metodo già utilizzato dai colleghi nel loro progetto per il cliente X per un caso d'uso completamente non correlato: Ugh.

modifica: Un altro aspetto importante è menzionato da gnasher729 . Spesso si desidera aggiungere dinamicamente proprietà opzionali a un oggetto esistente. Con l'ereditarietà o le interfacce dovresti ricreare l'intero oggetto con un'altra classe che è tutt'altro che facoltativa.

Quando ti aspetti estensioni del tuo modello di oggetto a tal punto, starai meglio modellando esplicitamente la possibilità di estensione dinamica . Propongo qualcosa come sopra dove ogni "estensione" (in questo caso proprietà) ha la sua classe. La classe funziona come spazio dei nomi e identificatore per l'estensione. Quando si impostano le convenzioni di denominazione dei pacchetti di conseguenza, in questo modo si consente una quantità infinita di estensioni senza inquinare lo spazio dei nomi per i metodi nella classe di entità originale.

Nello sviluppo del gioco si incontrano spesso situazioni in cui si desidera comporre comportamenti e dati in molte varianti. Questo è il motivo per cui l'architettura modello entità-componente-sistema è diventato molto popolare nei circoli di sviluppo del gioco. Questo è anche un approccio interessante che potresti voler guardare quando ti aspetti molte estensioni al tuo modello di oggetti.

Se la Bookclasse è derivabile senza proprietà del colore come di seguito

class E_Book extends Book{
   private String type;
}

allora l'eredità è ragionevole.