Sto scrivendo un servizio Web con diverse API e condivideranno parte del codice di implementazione. Per non copiare e incollare, vorrei implementare idealmente ogni chiamata API come una serie di attività, che vengono eseguite in una sequenza determinata dalla logica aziendale.
Una domanda ovvia è se questa è la migliore strategia per il riutilizzo del codice, o se posso guardarla in un modo diverso. Ma supponendo che voglio andare con le attività, sorgono diversi problemi:
- Quale interfaccia di una buona attività usare?
- Come faccio a passare i dati calcolati in un'attività a un'altra attività nella sequenza che potrebbe averne bisogno?
In passato, ho lavorato con interfacce come:
interface Task<T, U> {
U execute(T input);
}
Poi ho avuto anche una sorta di oggetto "contesto di attività" che aveva getter e setter per qualsiasi tipo di dati i miei compiti necessari per produrre o consumare, e viene passato a tutte le attività. Sono consapevole che questo soffre di una serie di problemi. Quindi volevo capire un modo migliore per implementarlo questa volta.
La mia idea attuale è di avere un oggetto TaskContext che sia un contenitore eterogeneo sicuro per il tipo (come descritto in Java efficace). Ogni attività può richiedere un elemento da questo contenitore (input dell'attività) o aggiungere un elemento al contenitore (output dell'attività). In questo modo, le attività non hanno bisogno di conoscersi direttamente l'un l'altro, e non devo scrivere una classe con dozzine di metodi per ogni elemento di dati. Ci sono, tuttavia, diversi inconvenienti:
-
Ogni elemento in questo contenitore TaskContext dovrebbe essere un tipo complesso che ricopre i dati effettivi degli articoli. Se l'attività A utilizza una stringa per un determinato scopo e l'attività B utilizza una stringa per qualcosa di completamente diverso, la semplice memorizzazione di una mappatura tra String.class e alcuni oggetti non funziona per entrambe le attività. L'altro motivo è che non posso usare direttamente quel tipo di contenitore per le raccolte generiche, quindi devono essere racchiusi in un altro oggetto.
-
Ciò significa che, in base al numero di attività che definisco, dovrei anche definire un numero di classi per gli elementi dell'attività che possono essere consumati o prodotti, il che può portare a un aumento di codice e alla duplicazione. Ad esempio, se un'attività richiede un valore Long come input e produce un altro valore Long come output, dovrei avere due classi che si sovrappongono semplicemente a Long, che IMO può fuoriuscire senza controllo abbastanza rapidamente man mano che il codebase evolve.
Ho esaminato brevemente le librerie del motore del flusso di lavoro, ma sembrano un martello pesante per questo particolare chiodo. Come andresti a scrivere un semplice framework di attività con i seguenti requisiti:
-
Le attività dovrebbero essere quanto più indipendenti possibile, in modo che possano essere composte in diversi modi per creare diversi flussi di lavoro.
-
Detto questo, alcune attività possono eseguire calcoli costosi che sono prerequisiti per altre attività. Vogliamo avere un modo per archiviare i risultati dei calcoli intermedi eseguiti dalle attività in modo che altre attività possano utilizzare tali risultati gratuitamente.
-
Il framework delle attività dovrebbe essere leggero, cioè la crescita del codice non comporta l'introduzione di molti nuovi tipi solo per collegarsi al framework.