Come affrontare le mostruose azioni Struts?

StackOverflow https://stackoverflow.com/questions/209516

Domanda

Ho ereditato questa gigantesca app Web Java legacy usando Struts 1.2.4. Ho una domanda specifica riguardante le azioni. La maggior parte delle pagine ha esattamente un'azione e i metodi processExecute () sono mostri orrendi (molto lunghi e tonnellate di istruzioni nidificate se basate su parametri di richiesta).

Dato che le azioni sono un'implementazione del modello di comando, sto pensando di dividere queste azioni in un'azione per gesto dell'utente. Questo sarà un grande refactoring però, e mi chiedo:

  1. È questa la direzione giusta?
  2. C'è un passo intermedio che potrei fare, un modello che affronta il disordine all'interno delle azioni monolitiche? Forse un altro modello di comando all'interno dell'Azione?
È stato utile?

Soluzione

Il mio modo di affrontarlo sarebbe:

  • non fare "tutto in una volta"
  • ogni volta che cambi qualcosa, lascialo meglio di come l'hai trovato
    • la sostituzione dei condizionali con implementazioni di azioni separate è un passo.
    • Meglio ancora: separa le tue implementazioni dalle classi di azione in modo da poterle utilizzare quando cambi i framework
    • Mantieni la tua nuova implementazione di comando assolutamente senza riferimenti a Struts, usa le tue nuove azioni come wrapper per queste implementazioni.
    • Potrebbe essere necessario fornire interfacce ai moduli azione Struts per farli passare senza copiare tutti i dati. D'altra parte, potresti voler passare attorno ad altri oggetti diversi da ActionForm che di solito sono un mucchio di stringhe (vedi l'altra domanda su Struts 1.2 ActionForms )
  • avvia la migrazione di parti al più recente & amp; migliore tecnologia. Struts 1.2 è stato fantastico quando è uscito, ma sicuramente non è ciò che vuoi supportare nell'eternità. Ci sono alcune generazioni di framework migliori ora.

C'è sicuramente di più - Scusa, sto esaurendo il tempo qui ...

Altri suggerimenti

Le azioni Struts, secondo me, non dovrebbero contenere molto codice. Dovrebbero semplicemente interagire direttamente con la richiesta e la risposta: prendere alcuni dati da un modulo o un parametro di richiesta, consegnare tali informazioni al livello di servizio, quindi inserire alcune cose in un oggetto Response o forse salvare alcuni dati nella sessione dell'utente.

Consiglio di stare lontano dal fare l'eredità con le classi di azione. All'inizio sembra una buona idea, ma penso che prima o poi ti renderai conto che stai facendo cose da sbavare più di quanto tu stia effettivamente rendendo solida la base di codice. Struts ha abbastanza azioni di base così com'è, se ne stai creando di nuove probabilmente hai un codice nel livello web che non dovrebbe essere lì.

Questa è solo la mia esperienza personale.

Ho già affrontato questo tipo di cose prima. Un buon primo passo è inserire un'altra classe di base nella catena di ereditarietà tra Action e una delle classi di azioni mostruose originali (chiamiamola ClassA). Soprattutto se non hai tempo di fare tutto in una volta. Quindi puoi iniziare a estrarre funzionalità in classi di azioni parallele più piccole (Classe B, Classe C). Tutto ciò che è comune tra la Classe A originale e le nuove classi refactored può essere inserito nella nuova classe base. Quindi la gerarchia ora appare così: 

Original Hierarchy:      New Hierarchy:

     Action                   Action
       |                        |
       |                      BaseA
  (old)ClassA                   |
                       +--------+----------+
                       |        |          |
                   ClassB (new)ClassA   ClassC
  1. Utilizza un metodo alla volta
  2. Registra alcuni casi di test che puoi riprodurre in seguito. Esempio qui (assicurati di raggiungere il maggior numero di percorsi nel codice che puoi, cioè tutti i gesti degli utenti sulla pagina che chiamano questa azione)
  3. rifattorizza il metodo per ridurne la complessità creando metodi più piccoli che fanno cose più piccole.
  4. Riesegui i test mentre esegui questa operazione

A questo punto, hai modificato la versione del grande metodo fastidioso. Ora puoi effettivamente iniziare a creare azioni specifiche.

Puoi usare la tua nuova classe refactored come classe base e implementare ogni azione specifica come sottoclasse usando quei piccoli metodi refactored.

Una volta fatto questo, dovresti avere una buona immagine della logica condivisa tra le classi e puoi estrarre o spingere quei metodi secondo necessità.

Non è divertente, ma se lavorerai sul codebase per un po ', ti farà risparmiare tempo e mal di testa.

Problema difficile ma tipico dello sviluppo iniziale di app Web.

Per prima cosa devi iniziare a pensare a quale logica costituisce il comportamento aziendale, quale logica costituisce "flusso" (ovvero ciò che l'utente vede) e quale logica ottiene il contenuto per ciò che vede.

Non devi percorrere la strada delle fabbriche e delle interfacce e tutto il resto; l'implementazione retroattiva è molto meno utile ... ma consolidare la logica aziendale e la logica di recupero dei dati in delegati di qualche tipo ... e lasciare le azioni strut per determinare il flusso di pagine in base al successo / fallimento di quella logica.

Da lì devi solo prendere alcune settimane e macinarlo

Un metodo lungo non è mai buono, a meno che non si tratti di una singola istruzione switch in cui i casi sono molto brevi (analisi dei token o qualcosa del genere).

Potresti almeno trasformare il metodo lungo in metodi più piccoli con nomi descrittivi.

Se possibile, puoi iniziare il tuo metodo riconoscendo che cosa dovrebbe fare esaminando il modulo, e poi se / altrimenti raggiungi le varie opzioni. Nessun if nidificato però, quelli tendono a rendere illeggibile il codice. Solo 

enum Operation {
  ADD, DELETE;
}

...

Operation operation = determineOperation(form);
if (operation == Operation.DELETE) { 
  doDelete(form); 
} else if (operation == Operation.ADD) {
  doAdd(form);
}

Se riesci ad andare così lontano, la tua logica è bella e pulita e puoi fare tutto il refactoring che desideri.

La parte difficile è chiarire la tua logica, e puoi farlo in pochi passaggi. Non scegliere un modello fino a quando non capisci esattamente qual è il tuo problema.

Se stai pianificando di eseguire il refactoring del codice, assicurati di scrivere prima i test per il codice esistente in modo da poter essere sicuro di non averne alterato la funzionalità una volta iniziato il refactoring.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top