Ho una classe di base, Base. Ha due sottoclassi Sub1e Sub2. Ogni sottoclasse ha alcuni metodi aggiuntivi. Ad esempio, Sub1ha Sandwich makeASandwich(Ingredients... ingredients)e Sub2ha boolean contactAliens(Frequency onFrequency).

Poiché questi metodi adottano parametri diversi e fanno cose completamente diverse, sono completamente incompatibili e non posso semplicemente usare il polimorfismo per risolvere questo problema.

Basefornisce la maggior parte delle funzionalità e ho una vasta collezione di Baseoggetti. Tuttavia, tutti gli Baseoggetti sono o a Sub1o a Sub2volte e a volte ho bisogno di sapere quali sono.

Sembra una cattiva idea fare quanto segue:

for (Base base : bases) {
    if (base instanceof Sub1) {
        ((Sub1) base).makeASandwich(getRandomIngredients());
        // ... etc.
    } else { // must be Sub2
        ((Sub2) base).contactAliens(getFrequency());
        // ... etc.
    }
}

Quindi ho escogitato una strategia per evitarlo senza lanciare. Baseora ha questi metodi:

boolean isSub1();
Sub1 asSub1();
Sub2 asSub2();

E, naturalmente, Sub1implementa questi metodi come

boolean isSub1() { return true; }
Sub1 asSub1();   { return this; }
Sub2 asSub2();   { throw new IllegalStateException(); }

E Sub2li implementa in modo opposto.

Purtroppo, ora Sub1e Sub2hanno questi metodi nella loro API. Quindi posso farlo, per esempio, su Sub1.

/** no need to use this if object is known to be Sub1 */
@Deprecated
boolean isSub1() { return true; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub1 asSub1();   { return this; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub2 asSub2();   { throw new IllegalStateException(); }

In questo modo, se si sa che l'oggetto è solo a Base, questi metodi non sono deprecati e possono essere usati per "lanciarsi" su un tipo diverso in modo da poter invocare i metodi della sottoclasse su di esso. Questo mi sembra elegante in un certo senso, ma d'altra parte sto abusando delle annotazioni obsolete come un modo per "rimuovere" i metodi da una classe.

Dal momento che Sub1un'istanza è davvero una Base, ha senso usare l'ereditarietà piuttosto che l'incapsulamento. Quello che sto facendo è buono? C'è un modo migliore per risolvere questo problema?

Non ha sempre senso aggiungere funzioni alla classe base, come suggerito in alcune delle altre risposte. L'aggiunta di troppe funzioni di casi speciali può comportare l'associazione di componenti altrimenti non correlati.

Ad esempio potrei avere una Animalclasse, con Cate Dogcomponenti. Se voglio essere in grado di stamparli o mostrarli nella GUI, potrebbe essere eccessivo aggiungere renderToGUI(...)e sendToPrinter(...)alla classe base.

L'approccio che stai usando, usando i controlli di tipo e i cast, è fragile, ma almeno mantiene separate le preoccupazioni.

Tuttavia, se ti ritrovi a fare questi tipi di controlli / cast spesso, un'opzione è quella di implementare il modello visitatore / doppio invio per questo. Sembra un po 'così:

public abstract class Base {
  ...
  abstract void visit( BaseVisitor visitor );
}

public class Sub1 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub1(this); }
}

public class Sub2 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub2(this); }
}

public interface BaseVisitor {
   void onSub1(Sub1 that);
   void onSub2(Sub2 that);
}

Ora il tuo codice diventa

public class ActOnBase implements BaseVisitor {
    void onSub1(Sub1 that) {
       that.makeASandwich(getRandomIngredients())
    }

    void onSub2(Sub2 that) {
       that.contactAliens(getFrequency());
    }
}

BaseVisitor visitor = new ActOnBase();
for (Base base : bases) {
    base.visit(visitor);
}

Il vantaggio principale è che se aggiungi una sottoclasse, otterrai errori di compilazione anziché casi mancanti in silenzio. La nuova classe visitatore diventa anche un bel bersaglio per attirare funzioni. Per esempio potrebbe avere senso per muoversi getRandomIngredients()in ActOnBase.

Puoi anche estrarre la logica del loop: ad esempio il frammento sopra potrebbe diventare

BaseVisitor.applyToArray(bases, new ActOnBase() );

Un altro po 'di massaggio e l'utilizzo delle lambda e dello streaming di Java 8 ti permetterebbero di farlo

bases.stream()
     .forEach( BaseVisitor.forEach(
       Sub1 that -> that.makeASandwich(getRandomIngredients()),
       Sub2 that -> that.contactAliens(getFrequency())
     ));

Quale IMO è più bello e succinto che puoi ottenere.

Ecco un esempio più completo di Java 8:

public static abstract class Base {
    abstract void visit( BaseVisitor visitor );
}

public static class Sub1 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub1(this); }

    void makeASandwich() {
        System.out.println("making a sandwich");
    }
}

public static class Sub2 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub2(this); }

    void contactAliens() {
        System.out.println("contacting aliens");
    }
}

public interface BaseVisitor {
    void onSub1(Sub1 that);
    void onSub2(Sub2 that);

    static Consumer<Base> forEach(Consumer<Sub1> sub1, Consumer<Sub2> sub2) {

        return base -> {
            BaseVisitor baseVisitor = new BaseVisitor() {

                @Override
                public void onSub1(Sub1 that) {
                    sub1.accept(that);
                }

                @Override
                public void onSub2(Sub2 that) {
                    sub2.accept(that);
                }
            };
            base.visit(baseVisitor);
        };
    }
}

Collection<Base> bases = Arrays.asList(new Sub1(), new Sub2());

bases.stream()
     .forEach(BaseVisitor.forEach(
             Sub1::makeASandwich,
             Sub2::contactAliens));

Dal mio punto di vista: il tuo design è sbagliato .

Tradotto in linguaggio naturale, stai dicendo quanto segue:

Dato che abbiamo animals, ci sono catse fish. animalshanno proprietà comuni a catse fish. Ma non è abbastanza: ci sono alcune proprietà, che si differenziano catda fish, quindi è necessario sottoclassare.

Ora hai il problema, che hai dimenticato di modellare il movimento . Va bene. È relativamente facile:

for(Animal a : animals){
   if (a instanceof Fish) swim();
   if (a instanceof Cat) walk();
}

Ma questo è un design sbagliato. Il modo corretto sarebbe:

for(Animal a : animals){
    animal.move()
}

Dove movesarebbero condivisi comportamenti attuati in modo diverso da ciascun animale.

Poiché questi metodi adottano parametri diversi e fanno cose completamente diverse, sono completamente incompatibili e non posso semplicemente usare il polimorfismo per risolvere questo problema.

Questo significa: il tuo design è rotto.

La mia raccomandazione: refactoring Base, Sub1e Sub2.

È un po 'difficile immaginare una circostanza in cui hai un gruppo di cose e vuoi che facciano un panino o contatti gli alieni. Nella maggior parte dei casi in cui trovi tale casting, opererai con un tipo, ad esempio in clang filtrerai un insieme di nodi per le dichiarazioni in cui getAsFunction restituisce un valore non nullo, anziché fare qualcosa di diverso per ciascun nodo nell'elenco.

Potrebbe essere necessario eseguire una sequenza di azioni e in realtà non è rilevante che gli oggetti che eseguono l'azione siano correlati.

Quindi, anziché un elenco di Base, lavorare sull'elenco di azioni

for (RandomAction action : actions)
   action.act(context);

dove

interface RandomAction {
    void act(Context context);
} 

interface Context {
    Ingredients getRandomIngredients();
    double getFrequency();
}

Se necessario, puoi fare in modo che Base attui un metodo per restituire l'azione, o qualsiasi altro mezzo tu debba selezionare l'azione dalle istanze nel tuo elenco di base (poiché dici che non puoi usare il polimorfismo, quindi presumibilmente l'azione da intraprendere non è una funzione della classe ma qualche altra proprietà delle basi; altrimenti daresti semplicemente il metodo Base the act (Context))

Che ne dici se le tue sottoclassi implementano una o più interfacce che definiscono cosa possono fare? Qualcosa come questo:

interface SandwichCook
{
    public void makeASandwich(String[] ingredients);
}

interface AlienRadioSignalAwarable
{
    public void contactAliens(int frequency);

}

Quindi le tue lezioni saranno così:

class Sub1 extends Base implements SandwichCook
{
    public void makeASandwich(String[] ingredients)
    {
        //some code here
    }
}

class Sub2 extends Base implements AlienRadioSignalAwarable
{
    public void contactAliens(int frequency)
    {
        //some code here
    }
}

E il tuo for-loop diventerà:

for (Base base : bases) {
    if (base instanceof SandwichCook) {
        base.makeASandwich(getRandomIngredients());
    } else if (base instanceof AlienRadioSignalAwarable) {
        base.contactAliens(getFrequency());
    }
}

Due principali vantaggi di questo approccio:

• nessun casting coinvolto
• puoi avere ciascuna sottoclasse implementare tutte le interfacce che desideri, il che fornisce una certa flessibilità per le modifiche future.

PS: Mi dispiace per i nomi delle interfacce, non riuscivo a pensare a niente di più interessante in quel particolare momento: D.

L'approccio può essere una buona nei casi in cui qualsiasi tipo di un famiglia sia direttamente utilizzabile come attuazione di alcune interfaccia che soddisfa un criterio o può essere usato per creare un'implementazione di tale interfaccia. I tipi di raccolta incorporati avrebbero beneficiato di questo modello IMHO, ma dal momento che non a scopo di esempio inventerò un'interfaccia di raccolta BunchOfThings<T>.

Alcune implementazioni di BunchOfThingssono mutabili; alcuni non lo sono. In molti casi, un oggetto Fred potrebbe voler contenere qualcosa che può usare come un BunchOfThingse sapere che nient'altro che Fred sarà in grado di modificarlo. Questo requisito può essere soddisfatto in due modi:

1. Fred sa che contiene gli unici riferimenti a ciò BunchOfThings, e nessun riferimento esterno a quello dei BunchOfThingssuoi interni esiste ovunque nell'universo. Se nessun altro ha un riferimento al BunchOfThingssuo interno o, nessun altro sarà in grado di modificarlo, quindi il vincolo sarà soddisfatto.

2. Né il suo BunchOfThings, né alcuno dei suoi interni a cui esistono riferimenti esterni, può essere modificato con qualsiasi mezzo. Se assolutamente nessuno può modificare a BunchOfThings, il vincolo sarà soddisfatto.

Un modo per soddisfare il vincolo sarebbe copiare incondizionatamente qualsiasi oggetto ricevuto (elaborazione ricorsiva di qualsiasi componente nidificato). Un altro sarebbe verificare se un oggetto ricevuto promette immutabilità e, in caso contrario, crearne una copia e fare altrettanto con qualsiasi componente nidificato. Un'alternativa, che dovrebbe essere più pulita della seconda e più veloce della prima, è quella di offrire un AsImmutablemetodo che richiede a un oggetto di fare una copia immutabile di se stesso (usando AsImmutablesu tutti i componenti nidificati che lo supportano).

Potrebbero anche essere previsti metodi correlati asDetached(da utilizzare quando il codice riceve un oggetto e non sa se vorrà mutarlo, nel qual caso un oggetto mutabile dovrebbe essere sostituito con un nuovo oggetto mutabile, ma un oggetto immutabile può essere mantenuto così com'è) asMutable(nel caso in cui un oggetto sappia che conterrà un oggetto precedentemente restituito asDetached, ovvero un riferimento non condiviso a un oggetto mutabile o un riferimento condivisibile a un oggetto mutabile) e asNewMutable(nei casi in cui il codice riceve un oggetto esterno riferimento e sa che vorrà mutare una copia dei dati al suo interno - se i dati in arrivo sono mutabili non c'è motivo di iniziare facendo una copia immutabile che verrà immediatamente utilizzata per creare una copia mutabile e quindi abbandonata).

Si noti che mentre i asXXmetodi possono restituire tipi leggermente diversi, il loro vero ruolo è garantire che gli oggetti restituiti soddisfino le esigenze del programma.

Ignorando la questione del fatto che tu abbia un buon design o meno, e supponendo che sia buono o almeno accettabile, vorrei considerare le capacità delle sottoclassi, non il tipo.

Pertanto, sia:

Sposta alcune conoscenze dell'esistenza di sandwich e alieni nella classe base, anche se sai che alcune istanze della classe base non possono farlo. Implementalo nella classe base per generare eccezioni e modifica il codice in:

if (base.canMakeASandwich()) {
    base.makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    base.contactAliens(getFrequency());
    // ... etc.
}

Quindi una o entrambe le sottoclassi hanno la precedenza canMakeASandwich()e solo una implementa ciascuna di makeASandwich()e contactAliens().

Utilizzare le interfacce, non le sottoclassi concrete, per rilevare le capacità di un tipo. Lasciare sola la classe base e modificare il codice in:

if (base instanceof SandwichMaker) {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    ((AlienContacter)base).contactAliens(getFrequency());
    // ... etc.
}

o eventualmente (e sentiti libero di ignorare questa opzione se non si adatta al tuo stile, o del resto qualsiasi stile Java che considereresti sensato):

try {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
} catch (ClassCastException e) {
    ((AlienContacter)base).contactAliens(getFrequency());
}

Personalmente non di solito come quest'ultimo stile di catturare un'eccezione mezzo del previsto, a causa del rischio di impropriamente cattura di un ClassCastExceptionuscendo getRandomIngredientso makeASandwich, ma YMMV.

Qui abbiamo un caso interessante di una classe base che si riduce alle proprie classi derivate. Sappiamo benissimo che questo è normalmente negativo, ma se vogliamo dire che abbiamo trovato una buona ragione, cerchiamo di guardare e vedere quali potrebbero essere i vincoli su questo:

1. Possiamo coprire tutti i casi nella classe base.
2. Nessuna classe di derivazione straniera dovrebbe mai aggiungere un nuovo caso.
3. Possiamo convivere con la politica per la quale chiamare per essere sotto il controllo della classe base.
4. Ma sappiamo dalla nostra scienza che la politica di cosa fare in una classe derivata per un metodo non nella classe base è quella della classe derivata e non della classe base.

Se 4, allora abbiamo: 5. La politica della classe derivata è sempre sotto lo stesso controllo politico della politica della classe base.

2 e 5 implicano entrambi direttamente che possiamo enumerare tutte le classi derivate, il che significa che non si suppone che ci siano classi derivate esterne.

Ma ecco la cosa. Se sono tutti tuoi, puoi sostituire l'if con un'astrazione che è una chiamata di metodo virtuale (anche se è una sciocchezza) e sbarazzarti dell'if e del cast personale. Pertanto, non farlo. È disponibile un design migliore.

Inserisci un metodo astratto nella classe base che fa una cosa in Sub1 e l'altra in Sub2 e chiama quel metodo astratto nei tuoi loop misti.

class Sub1 : Base {
    @Override void doAThing() {
        this.makeASandwich(getRandomIngredients());
    }
}

class Sub2 : Base {
    @Override void doAThing() {
        this.contactAliens(getFrequency());
    }
}

for (Base base : bases) {
    base.doAThing();
}

Si noti che ciò potrebbe richiedere altre modifiche a seconda della definizione di getRandomIngredients e getFrequency. Ma, onestamente, all'interno della classe che contatta gli alieni è probabilmente un posto migliore per definire getFrequency comunque.

Per inciso, i tuoi metodi asSub1 e asSub2 sono decisamente cattive pratiche. Se hai intenzione di farlo, fallo lanciando. Non c'è niente che questi metodi ti diano che il casting non lo fa.

Si potrebbe spingere sia makeASandwiche contactAliensnella classe di base e poi implementare con le implementazioni fittizie. Poiché i tipi / argomenti di ritorno non possono essere risolti in una classe base comune.

class Sub1 extends Base{
    Sandwich makeASandwich(Ingredients i){
        //Normal implementation
    }
    boolean contactAliens(Frequency onFrequency){
        return false;
    }
 }
class Sub2 extends Base{
    Sandwich makeASandwich(Ingredients i){
        return null;
    }
    boolean contactAliens(Frequency onFrequency){
       // normal implementation
    }
 }

Ci sono evidenti inconvenienti in questo genere di cose, come ciò che ciò significa per il contratto del metodo e ciò che si può e non si può dedurre dal contesto del risultato. Non puoi pensare da quando non sono riuscito a fare un panino gli ingredienti si sono consumati nel tentativo ecc.

Quello che stai facendo è perfettamente legittimo. Non prestare attenzione agli oppositori che semplicemente ribadiscono il dogma perché lo leggono in alcuni libri. Dogma non ha posto nell'ingegneria.

Ho utilizzato lo stesso meccanismo un paio di volte e posso dire con sicurezza che il runtime java avrebbe potuto fare la stessa cosa in almeno un posto a cui riesco a pensare, migliorando così le prestazioni, l'usabilità e la leggibilità del codice che lo usa.

Prendiamo ad esempio java.lang.reflect.Member, che è la base di java.lang.reflect.Fielde java.lang.reflect.Method. (La gerarchia attuale è un po 'più complicata di così, ma questo è irrilevante.) Campi e metodi sono animali molto diversi: uno ha un valore che puoi ottenere o impostare, mentre l'altro non ha tale cosa, ma può essere invocato con un numero di parametri e può restituire un valore. Quindi, campi e metodi sono entrambi membri, ma le cose che puoi fare con loro sono diverse l'una dall'altra quanto fare sandwich e contattare alieni.

Ora, quando scriviamo un codice che usa la riflessione abbiamo molto spesso un Membernelle nostre mani e sappiamo che è o a Methodo Field(o, raramente, qualcos'altro), eppure dobbiamo fare tutto il noioso instanceofper capire con precisione di cosa si tratta e quindi dobbiamo lanciarlo per ottenere un riferimento adeguato ad esso. (E questo non è solo noioso, ma non funziona molto bene.) La Methodclasse avrebbe potuto implementare molto facilmente il modello che stai descrivendo, rendendo così più facile la vita di migliaia di programmatori.

Naturalmente, questa tecnica è praticabile solo in piccole gerarchie ben definite di classi strettamente accoppiate di cui hai (e avrai sempre) il controllo a livello di sorgente di: non vuoi fare una cosa del genere se la tua gerarchia di classi è rischia di essere esteso da persone che non sono libere di riformattare la classe base.

Ecco come ciò che ho fatto differisce da quello che hai fatto:

• La classe base fornisce un'implementazione predefinita per l'intera asDerivedClass()famiglia di metodi, con ognuno di essi restituito null.

• Ogni classe derivata sovrascrive solo uno dei asDerivedClass()metodi, restituendo thisinvece di null. Non ha la precedenza su tutto il resto, né vuole sapere nulla su di loro. Quindi, non IllegalStateExceptionvengono lanciate s.

• La classe base fornisce anche finalimplementazioni per l'intera isDerivedClass()famiglia di metodi, codificata come segue: In return asDerivedClass() != null; questo modo, il numero di metodi che devono essere sostituiti da classi derivate è ridotto al minimo.

• Non ho usato @Deprecatedquesto meccanismo perché non ci avevo pensato. Ora che mi hai dato l'idea, la metterò in pratica, grazie!

C # ha un meccanismo correlato incorporato tramite l'uso della asparola chiave. In C # puoi dire DerivedClass derivedInstance = baseInstance as DerivedClasse otterrai un riferimento a DerivedClassse tu fossi baseInstancedi quella classe o nullse non lo fosse. Questo (teoricamente) ha prestazioni migliori di quelle isseguite dal cast ( isè certamente la parola chiave C # meglio denominata per instanceof), ma il meccanismo personalizzato che abbiamo realizzato a mano funziona ancora meglio: la coppia di instanceofoperazioni -e-cast di Java in quanto l' asoperatore di C # non ha la stessa velocità del singolo metodo virtuale del nostro approccio personalizzato.

Con la presente ho avanzato la proposta secondo cui questa tecnica dovrebbe essere dichiarata come modello e che dovrebbe essere trovato un bel nome.

Accidenti, grazie per il voto negativo!

Un riassunto della controversia, per salvarti dalla difficoltà di leggere i commenti:

L'obiezione della gente sembra essere che il progetto originale fosse sbagliato, nel senso che non dovresti mai avere classi molto diverse derivanti da una classe base comune, o che anche se lo fai, il codice che utilizza tale gerarchia non dovrebbe mai essere nella posizione di avere un riferimento di base e la necessità di capire la classe derivata. Pertanto, dicono, il meccanismo di autoprofusione proposto da questa domanda e dalla mia risposta, che migliora l'uso del design originale, non avrebbe mai dovuto essere necessario in primo luogo. (In realtà non dicono nulla sul meccanismo stesso di auto-fusione, si lamentano solo della natura dei disegni a cui il meccanismo dovrebbe essere applicato.)

Tuttavia, nell'esempio di cui sopra mi hanno già dimostrato che i creatori del runtime Java hanno infatti scegliere il disegno di un proprio come per il java.lang.reflect.Member, Field, Methodgerarchia e nei commenti qui sotto ho anche mostrano che i creatori del C # runtime sono arrivati in modo indipendente ad un equivalente di progettazione per il System.Reflection.MemberInfo, FieldInfo, MethodInfogerarchia. Quindi, questi sono due diversi scenari del mondo reale che si trovano proprio sotto il naso di tutti e che hanno soluzioni dimostrabili realizzabili usando esattamente tali progetti.

Questo è ciò a cui si riducono tutti i seguenti commenti. Il meccanismo di autofusione è appena menzionato.