Quale opzione di progettazione è meglio utilizzare nella codifica di un framework?

Question

Sto codificando un framework (in Java, ma la domanda è generica) in cui fornirò una serie di interfacce per l'implementazione dei client. Le funzioni nel framework dipenderanno dal modo in cui saranno costruite le classi di implementazione, ovvero dipenderanno da tali implementazioni per fornire altre istanze di interfacce.

Ad esempio potrei avere:

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

Come posso assicurarmi che quelle istanze di IMyStuff e IHelper siano disponibili?

Un metodo sarebbe quello di creare i metodi "getter" nell'interfaccia e nel mio framework controllare scrupolosamente gli oggetti nulli restituiti.

Un'altra opzione sarebbe quella di creare classi astratte che implementano una fabbrica che chiama (usando uno schema di strategia) i metodi di interfaccia da implementare. Ma questo sfida il fatto che ho l'interfaccia in primo luogo. I clienti dovrebbero quindi utilizzare la classe astratta. Ma potrebbero eludere questo usando l'interfaccia invece della classe astratta. Pertanto non dovrei fornire l'interfaccia ma solo la classe astratta ...

Quindi, quali sono le tue idee al riguardo, qual è un approccio pragmatico a questo?

Answer 1

  

Come posso assicurarmi che quelle istanze di IMyStuff e IHelper siano disponibili?

Se i clienti sono responsabili dell'implementazione delle interfacce e delle classi stesse, direi che è loro responsabilità assicurarsi che tali istanze siano disponibili - non mi preoccuperei di inserirle nel mio codice.

Answer 2

Per creare un buon framework, è necessario creare contemporaneamente un'applicazione attorno ad esso. In questo modo conoscerai e capirai il dolore che i tuoi clienti dovranno sopportare PRIMA che venga soffocato su di loro.

In altre parole, inizia con: Come funzionerebbero i miei clienti con questa applicazione? Come devono lavorare con esso?

Comprenderai immediatamente che il modo più semplice, dal loro punto di vista, sarà il migliore.

Answer 3

Non puoi assicurarlo solo con le interfacce, nessun comportamento lì.

Sono d'accordo con la filosofia della programmazione difensiva nel Framework, aiuto gli sviluppatori a evitare di commettere errori.

Puoi fornire un oggetto factory:

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

Quindi almeno possiamo verificare la presenza di null ecc.

Di solito è possibile dare aiuto agli sviluppatori. In alcuni casi il meglio che puoi fare è intrappolare gli errori e segnalarli con arroganza. Ad esempio qui, un IHelper perfettamente perfetto potrebbe essere passato alla tua fabbrica, ma in seguito le azioni sulla classe potrebbero renderlo incapace. (ad es. Immagine era un file e un effetto collaterale in seguito ha chiuso il file.) Quindi tutto ciò che puoi fare è intercettare la condizione di errore risultante, registrare un errore da qualche parte e (probabilmente) generare un'eccezione. Quindi almeno lo sviluppatore ha un indizio su cosa risolvere.