Qual è un buon esempio di a cross-cutting concern ? L'esempio di cartella clinica sulla pagina di wikipedia mi sembra incompleto.
In particolare da questo esempio, perché la registrazione porterebbe alla duplicazione del codice ( scattering )? (Oltre a semplici chiamate come log("....")ovunque, che non sembra un grosso problema).
Qual è la differenza tra a core concern e a cross-cutting concern?
Il mio obiettivo finale è ottenere una migliore comprensione della AOP.
Risposte:
Prima di comprendere la preoccupazione trasversale , dobbiamo capire la preoccupazione .
A Concern è un termine che si riferisce a una parte del sistema suddivisa in base alla funzionalità.
Le preoccupazioni sono di due tipi:
Questa figura rappresenta un'applicazione tipica suddivisa in moduli. La preoccupazione principale di ogni modulo è fornire servizi per il suo particolare dominio. Tuttavia, ciascuno di questi moduli richiede anche funzionalità ausiliarie simili, come la registrazione della sicurezza e la gestione delle transazioni. Un esempio di problemi di crosscutting è il "logging", che viene spesso utilizzato nelle applicazioni distribuite per facilitare il debug tracciando le chiamate ai metodi. Supponiamo di eseguire la registrazione sia all'inizio che alla fine del corpo di ogni funzione. Ciò comporterà il taglio incrociato di tutte le classi che hanno almeno una funzione.
Penso che il miglior esempio di una preoccupazione trasversale sia il comportamento transazionale. Dover inserire blocchi try-catch con chiamate commit e rollback in tutti i metodi del servizio sarebbe repellente, ad esempio. Annotare i metodi con un pennarello 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 indica chi può chiamarlo e lasciare che alcuni consigli di AOP decidano se consentire o meno la chiamata al metodo, può essere preferibile alla gestione del codice del metodo di servizio.
L'implementazione della registrazione con il consiglio AOP potrebbe essere un modo per ottenere maggiore flessibilità, in modo da poter modificare ciò che viene registrato modificando un punto di unione. In pratica non vedo progetti che lo fanno molto spesso. In genere, l'utilizzo di una libreria come log4j che consente di filtrare per livello di registrazione e categoria, in fase di esecuzione se necessario, funziona abbastanza bene.
Una delle preoccupazioni principali è il motivo per cui l'applicazione esiste, la logica di business che l'applicazione automatizza. Se disponi di un'applicazione logistica che gestisce il trasporto di merci, capire quanto carico puoi imballare su un camion o qual è il percorso migliore da prendere per il camion per consegnare le consegne potrebbe essere una preoccupazione fondamentale. Le preoccupazioni trasversali sono in genere dettagli di implementazione che devono essere tenuti separati dalla logica aziendale.
Oltre alla risposta accettata, desidero menzionare un altro esempio per una preoccupazione trasversale: la comunicazione remota. Diciamo che voglio solo chiamare localmente altri componenti nel mio ecosistema come se fossero in esecuzione. Forse in alcuni casi lo fanno anche. Ma ora voglio eseguire i miei servizi distribuiti in un cloud o in un 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 ed effettuare una chiamata a distanza. Se tutto fosse in esecuzione, l'aspetto dovrebbe semplicemente inoltrare la chiamata locale. Sul lato chiamato, l'aspetto deserializza i dati, effettua la chiamata locale e restituisce il risultato.
Ora lasciate che vi racconti una piccola storia su cose "banali" come l'output di log: solo poche settimane fa ho refactoring una base di codice complessa, ma non troppo grande (circa 250.000 righe di codice) per un client. In poche centinaia di classi è stato utilizzato un tipo di framework di registrazione, in altre poche centinaia un altro. Poi c'erano diverse migliaia di righeSystem.out.println(*)dove in realtà avrebbe dovuto esserci l'output del registro. Quindi ho finito per sistemare migliaia di righe di codice sparse per tutta la base del codice. Fortunatamente ho potuto usare alcuni trucchi intelligenti in IntelliJ IDEA (ricerca e sostituzione strutturale) per velocizzare l'intera azione, ma ragazzo non pensi che sia stato banale! Certo, la registrazione del debug fortemente dipendente dal contesto si verificherà 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 degli utenti (registrazione delle chiamate a metodi limitati basati sui ruoli dell'utente) e così via possono essere facilmente implementati in alcuni aspetti senza che inquinino il codice sorgente. Lo sviluppatore di applicazioni quotidiano non ha bisogno di pensarci o anche di vedere le chiamate del logger sparse nella base del codice.
Posso fornire spiegazioni simili per altre preoccupazioni trasversali. Mantenere il codice pulito e libero da dispersioni e grovigli IMO è una questione di professionalità, non qualcosa di opzionale. Ultimo ma non meno importante, mantiene il codice leggibile, manutenibile, refactoring. Amen.
Le preoccupazioni trasversali sono gli scenari che dovrebbero essere sempre presenti indipendentemente dal tipo di applicazione.
Ad esempio, registrazione, sicurezza, profilazione delle prestazioni, localizzazione, accessibilità, transazione ecc. Indipendentemente dal software che stiamo costruendo, la registrazione è necessaria (altrimenti come qualcuno eseguirà il debug o otterrà alcune informazioni rilevanti dai dati del prodotto). La sicurezza (autenticazione / autorizzazione ecc.) È necessaria quando solo l'utente autentico può accedere all'applicazione con il giusto set di privilegi. Abbiamo bisogno di sapere come funziona la tua applicazione, quindi dobbiamo fare la profilazione. Nel caso in cui l'applicazione venga utilizzata da utenti internazionali (con la propria lingua localizzata), è necessario supportare la stessa nell'applicazione. L'accessibilità è un caso di usabilità per le persone disabili che utilizzano la nostra applicazione.
Ora, indipendentemente dal fatto che la nostra applicazione sia basata su desktop, web e così via, se deve essere utilizzata dagli utenti finali in tutta l'area geografica nell'ambiente di produzione, sono necessari tagli incrociati. Finora non ho detto nulla su cosa sia l'applicazione, ecc., Ma dato l'elenco delle preoccupazioni che dovrebbero essere affrontate prima di rilasciarla agli utenti finali nell'ambiente di produzione. e questo è tutto su problemi di taglio incrociato (che deve essere gestito da tutte le applicazioni / metodi / classi, cioè a vari livelli).