Esempio di sollecito per taglio incrociato

Question

Che cos'è un buon esempio di cross-cutting concern? L'esempio di cartella clinica sulla pagina wikipedia mi sembra incompleto.

In particolare da questo esempio, perché il log di accesso porta alla duplicazione del codice (scattering)? (Oltre a semplici chiamate come log("....") ovunque, che non sembra un grosso problema).

Qual è la differenza tra uno core concern e uno cross-cutting concern?

Il mio obiettivo finale è ottenere una migliore comprensione di AOP.

Answer 1

Prima di comprendere l'Preoccupazione incrociata, dobbiamo comprendere l'Preoccupante.

Un preoccupazione è un termine che si riferisce ad una parte del sistema divisa sulla base della funzionalità.

preoccupazioni sono due tipi:

1. Le preoccupazioni rappresentano singola funzionalità e specifico per esigenze principali sono noti come nucleo riguarda.
   O
   La funzionalità principale del sistema è nota come preoccupazione principale.
   Ad esempio: logica conferenze
2. Le preoccupazioni rappresentano funzionalità per i requisiti secondari sono indicati come aspetti trasversali o di preoccupazioni a livello di sistema.
   O
   Il numero di intercettazione è un problema che è applicabile all'intera applicazione e interessa l'intera applicazione.
   Ad esempio: registrazione, sicurezza e trasferimento dati sono le preoccupazioni che sono necessarie in quasi tutti i moduli di un'applicazione, quindi sono preoccupazioni trasversali.

Courtesy

Questa figura rappresenta una tipica applicazione che viene suddiviso in moduli. La preoccupazione principale di ogni modulo è fornire servizi per il suo dominio particolare. Tuttavia, ciascuno di questi moduli richiede anche funzionalità ausiliarie simili, come la registrazione di sicurezza e la gestione delle transazioni. Un esempio di problemi trasversali è la "registrazione", che viene spesso utilizzata nelle applicazioni distribuite per facilitare il debugging tramite le chiamate al metodo di traccia. Supponiamo di fare il logging sia all'inizio che alla fine di ogni corpo di una funzione. Ciò si tradurrà in crosscutting di tutte le classi che hanno almeno una funzione.

(Courtesy)

Answer 2

Penso che il singolo migliore esempio di preoccupazione trasversale sia il comportamento transazionale. Ad esempio, mettere i blocchi try-catch con le chiamate di commit e rollback in tutti i tuoi metodi di servizio sarebbe repellente. Annotare i metodi con un marker che AOP può utilizzare per incapsularli con il comportamento transazionale desiderato è una grande vittoria.

Un altro buon candidato come esempio di preoccupazione trasversale è l'autorizzazione. Annotare un metodo di servizio con un indicatore che indichi chi può chiamarlo e lasciare che alcuni consigli AOP decidano se consentire la chiamata al metodo o meno, può essere preferibile alla gestione di quel codice del metodo di servizio.

L'implementazione della registrazione con la consulenza AOP può essere un modo per ottenere maggiore flessibilità, in modo che sia possibile modificare ciò che viene registrato modificando un joinpoint. In pratica, non vedo i progetti farlo molto spesso. In genere, l'utilizzo di una libreria come log4j che consente di filtrare per livello di registrazione e categoria, in caso di necessità, funziona abbastanza bene.

Un problema fondamentale è la ragione per cui esiste l'applicazione, la logica di business che l'applicazione automatizza. Se si dispone di un'applicazione logistica che gestisce il trasporto delle merci, determinare la quantità di carico che è possibile imballare su un camion o qual è il percorso migliore da intraprendere per il trasporto del camion per consegnare le consegne potrebbe essere un problema fondamentale. I problemi trasversali sono in genere dettagli di implementazione che devono essere tenuti separati dalla logica aziendale.

Answer 3

Oltre alla risposta accettata, desidero menzionare un altro esempio per una preoccupazione trasversale: il servizio remoto. Supponiamo che io voglia chiamare gli altri componenti del mio ecosistema localmente come se fossero in esecuzione. Forse in alcuni casi lo fanno anche loro. Ma ora voglio eseguire i miei servizi distribuiti in un cloud o cluster. Perché dovrei preoccuparmi di questo aspetto come sviluppatore di applicazioni? Un aspetto potrebbe occuparsi di scoprire chi chiamare e come, serializzare i dati trasmessi se necessario e effettuare una chiamata remota. Se tutto fosse in esecuzione in corso, l'aspetto semplicemente inoltrerebbe la chiamata locale. Dal lato del destinatario l'aspetto deserializza i dati, effettua la chiamata locale e restituisce il risultato.

Ora lascia che ti racconti una piccola storia di cose "banali" come l'output dei registri: solo poche settimane fa ho rifattorizzato un codice, ma non troppo grande, di codice (circa 250.000 righe di codice) per un client. In poche centinaia di classi è stato utilizzato un tipo di struttura di registrazione, in altre poche centinaia. Poi c'erano diverse migliaia di righe di System.out.println(*) dove in realtà doveva esserci stato l'output del registro. Così ho finito con il fissare migliaia di righe di codice sparse per il codice base. Fortunatamente potrei usare alcuni trucchi intelligenti in IntelliJ IDEA (ricerca strutturale & sostitutiva) per accelerare l'intera azione, ma ragazzo non pensi che sia stato banale! Certo, la registrazione di debug fortemente dipendente dal contesto si verifica sempre all'interno di un corpo del metodo, ma molti tipi importanti di registrazione come le chiamate al metodo di traccia (anche gerarchicamente con un output ben rientrato), la registrazione di eccezioni gestite o non gestite, il controllo dell'utente (registrazione delle chiamate a metodi ristretti basati su ruoli utente) e così via possono essere facilmente implementati in aspetti senza che essi inquinino il codice sorgente.Lo sviluppatore di applicazioni di tutti i giorni non ha bisogno di pensarci o persino di vedere le chiamate del registratore sparse sul codice base. Qualcuno è responsabile di mantenere aggiornato l'aspetto e può anche cambiare la strategia di registrazione o l'intera infrastruttura di registrazione centralmente in un unico posto.

Posso trovare spiegazioni simili per altri problemi trasversali. Mantenere il codice pulito e libero da dispersione e aggrovigliamento IMO è una questione di professionalità, non di nulla facoltativo. Ultimo ma non meno importante mantiene il codice leggibile, mantenibile, rifattorizzabile. Amen.