Livelli multipli di astrazione e chiamate a catena di metodi (programmazione funzionale Java)

Naviga le tue risposte
0

Sto creando un'API di wrapper / layer multipli in Java che vanno come questo

  1. public class Layer1<T extends Layer1>
  2. public class Layer2<T extends Layer2> extends Layer1<Layer2>
  3. public class Layer3 extends Layer2<Layer3>

con metodi come public T sees(){ return (T) this;} all'interno di ogni livello

Qual è il modo corretto per la struttura sopra di lavorare per essere in grado di mantenere l'oggetto originale, iniziamo la catena con, digitare durante la chiamata. Aka il seguente per essere fattibile: 3rdLayerObject.1stLayerMethod().2ndLayerMethod(); dove la chiamata al metodo 1stLayer restituisce un oggetto di primo livello (anziché la terza sottoclasse) e quindi chiamando un metodo di secondo livello restituisce un errore.

Perché l'API è strutturata in questo modo:

Primo livello ha solo i metodi che si applicano a tutte le situazioni

2nd layer ha metodi client specifici che sovrascrivono le implementazioni di base del 1st wrapper o sono completamente nuovi

Terzo livello ha metodi specifici del progetto che sono principalmente nuovi metodi usati solo da questo progetto.

Naturalmente, se pensi che la struttura di cui sopra sia difettosa e che ci sia un altro modello / struttura da utilizzare per organizzarlo in modo più efficace, sono aperto a tutte le idee.

    
posta Leon 04.09.2017 - 15:48
fonte

2 risposte

2

Da questa linea solo 3rdLayerObject.1stLayerMethod().2ndLayerMethod() Sospetto che tu voglia implementare qualcosa del genere: 

class Layer1<T extends Layer1<T>> {
    public T layer1Method(){
        return (T)this;
    }
}

class Layer2<T extends Layer2<T>> extends Layer1<T>{
    public T layer2Method(){
        return (T)this;
    }

}

class Layer3<T extends Layer3<T>> extends Layer2<T>{
    public T layer3Method(){
        return (T)this;
    }

    public static final <U extends Layer3<U>> U newLayer3Instance(){
        return (U)new Layer3();
    }

}

Così puoi farlo: 

Layer3.newLayer3Instance().layer1Method().layer2Method();

Ho faticato molto per ottenere una soluzione del genere. Sfortunatamente in Java, i generici stessi non sono abbastanza. Devi anche aggiungere un po 'di magia ..

--- EDIT

Il livello 4 sarebbe: 

class Layer4<T extends Layer4<T>> extends Layer3<T>{
    public T layer4Method(){
        System.out.println("layer4Method");
        return (T)this;
    }

    public static final <U extends Layer4<U>> U newLayer4Instance(){
        return (U)new Layer4();
    }

}

e.t.c ...

    
risposta data 05.09.2017 - 12:36
fonte
0

Sembra un'eredità ordinaria. Sembra anche che tu pensi di aver scoperto una verità ontologica sul mondo in cui vive questo software. Hai un nucleo di funzionalità, seguito da un'implementazione specifica del cliente, seguito da molti progetti in un determinato cliente.

Sembra un'astrazione ragionevole alla luce del tuo impegno ontologico. Sembra un modo ragionevole per organizzare il tuo codice.

Che cosa accade se desideri condividere un codice comune da un numero di client o di progetti all'interno dello stesso client o anche codice correlato al progetto tra i client?

Quelle classi nella tua gerarchia non saranno più le tue unità di riutilizzo del codice. Dovrai iniziare a spostare la funzionalità comune in altri moduli. È lì che inizierei a pensare all'architettura, dove l'astrazione si rompe.

Ma forse non hai mai bisogno di fare quanto sopra.

    
risposta data 04.09.2017 - 21:21
fonte

Leggi altre domande sui tag

Qual è un modello di progettazione efficace per "fan-in" da più thread di attività in un singolo thread dell'interfaccia utente? Cosa fare per molti tipi piccoli, semanticamente simili?