Funzioni opzionali: metodo predefinito o interfaccia separata

8

Le interfacce dedicate sembrano essere un buon modo per esporre le funzionalità opzionali in una gerarchia di tipi specifici del dominio. Tuttavia, impediscono l'uso di decorator e pattern compositi, che è anche comune in questo tipo di gerarchia.

Soprattutto, probabilmente nessuno vuole implementare un decoratore / composito per ogni possibile combinazione di queste interfacce, quindi molto spesso implementa tutte le interfacce opzionali e usa il controllo del tipo per inoltrare selettivamente le chiamate, il che sconfigge lo scopo di separare interfacce.

Un'alternativa, che utilizza il framework Java Collection, è quella di includere tutte le operazioni nel tipo di base e semplicemente riempirle con implementazioni fittizie. I metodi predefiniti in Java 8 facilitano ulteriormente questo utilizzo.

In un certo senso, sembra che le colonne annullabili dibattano nel mondo del database. C'è una strong argomentazione contro l'approccio più pratico di quest'ultimo?

    
posta billc.cn 24.07.2015 - 17:10
fonte

2 risposte

2

Una soluzione a questo problema che ho usato in passato (dove un gran numero di decoratori aggiunge facilità a una base relativamente semplice, con molte interfacce possibili) è di avere una classe base per entrambi i decoratori e le classi che avvolgono , indipendentemente dall'interfaccia che implementano, che ha dichiarato un metodo (usando la sintassi di Java):

    public <T> T findImplementation (Class<T> cls) {
       if (cls.isAssignableFrom(getClass())
           return cls.cast(this);
      return wrapped.findImplementation (cls);
   }

Ovviamente, le implementazioni di non decoratore restituiscono null invece di passare la richiesta, poiché in questo caso non c'è nulla da fare.

    
risposta data 29.08.2015 - 16:08
fonte
1

La sfida con l'alternativa è che rende più difficile l'aggiunta / modifica / rimozione di funzionalità opzionali. Ad esempio, se aggiungiamo una nuova funzione opzionale, ora dobbiamo modificare la classe base e quindi modificare tutte le sottoclassi per aggiungere la funzione o la non-funzione. Questo può essere in qualche modo mitigato se esiste un valore predefinito ragionevole, come un no-op, quindi solo i sottotipi che supportano la funzione devono sostituire le parti necessarie. Se queste funzionalità opzionali sono poche, relativamente stabili e improbabili da modificare, è sufficiente aggiungerle al supertipo. In caso contrario, la manutenzione può iniziare a diventare poco maneggevole.

Il modello di progettazione più comune per il recupero del tipo da supertipo è il modello di visitatore . Ciò potrebbe essere complicato nella tua situazione dal momento che un singolo oggetto può implementare più interfacce, ma potrebbe comunque essere possibile con alcune modifiche.

    
risposta data 29.07.2015 - 21:36
fonte

Leggi altre domande sui tag