Quali alternative ci sono per le preoccupazioni trasversali oltre alla programmazione orientata all'aspetto? [chiuso]

Quando possibile, puoi incapsulare preoccupazioni trasversali in moduli separati che vengono poi utilizzati in tutta l'app tramite l'integrazione delle dipendenze. Ciò ti consente di disaccoppiare in qualche modo l'implementazione dell'interesse cross-cut dal suo utilizzo in tutto il codice.

Tuttavia, questo non funziona sempre in modo elegante. Questo è il motivo per cui le persone stanno cercando di risolvere il problema con cose come AOP.

Altre due opzioni che non ho ancora visto:

Programmazione funzionale con Monade e frecce

In FP tu rappresenti una preoccupazione trasversale come qualsiasi altra cosa: come qualcosa che passi in una chiamata di funzione. Dal momento che farlo diventa noioso, puoi usare le Monade (o forse le Frecce) per nascondere le informazioni extra che vengono trasmesse.

L'esempio di AOP più comune è la registrazione. Con Monads, si crea una monade "Logger" che mantiene un elenco di messaggi. Le funzioni che esegui tramite LoggerMonad hanno la possibilità di inviare un messaggio di registro. Con le frecce, si modellerebbe l'intero flusso di dati dell'applicazione e si lavorerebbe una routine di registrazione nel modello, ove appropriato. Credo. Le frecce sono piuttosto complesse.

Programmazione basata su entità / componente

Qualcosa che ho cercato e sperimentato per un motore di gioco. Invece di "oggetti" come in OOP, decomponi tutto in pacchetti di dati (componenti) e servizi che operano su un tipo di componente. I componenti sono raggruppati per ID comuni, come in un database relazionale, e i gruppi di componenti collegati sono le Entità. Per aggiungere la registrazione in un sistema di questo tipo, devi aggiungere un nuovo servizio di registrazione ai trigger in base a quali componenti vengono passati attraverso di esso.

Entrambi i metodi consentono di lavorare facilmente un cambiamento trasversale in molto facilmente, ma entrambi sono modelli architettonici di alto livello. Quindi probabilmente dovresti usarli fin dall'inizio. Il modello di componente può, in teoria, essere lavorato in un sistema OOP esistente. Immagino che le monadi potrebbero esserlo anche se il tuo linguaggio è abbastanza potente.

Ci sono diversi modi per affrontare i problemi dei problemi trasversali:

• Usa modelli di progettazione, idiomi o meccanismi di astrazione migliori : il codice può essere di tipo incrociato anche se può essere modularizzato. Per mantenere il codice, dovrai rifattorizzare per utilizzare la tecnica di progettazione che può modularizzarlo. Tale refactoring può introdurre il crosscutting di un tipo diverso, ma si spera che le scorciatoie siano stabili e che non possano cambiare.

• Sviluppa funzionalità linguistiche più ricche : molte manifestazioni di crosscutting possono essere risolte attraverso migliori meccanismi di astrazione e talvolta sono necessarie nuove funzionalità linguistiche. Ad esempio, i linguaggi più avanzati che includono funzionalità funzionali e orientate agli oggetti spesso non utilizzano tanti schemi di progettazione, perché non sono necessari. Si noti che gli stessi schemi di progettazione possono essere incrociati in natura , perché descrivono i ruoli di diversi oggetti e classi. In Java, la riflessione può essere spesso utilizzata al posto di un aspetto, sebbene a un costo di runtime più elevato. Ad esempio, utilizzando la riflessione, è possibile supportare il modello di visitatore su centinaia di classi con solo un paio di linee di codice. La libreria DJ di Northeastern è una soluzione riflessiva che fa proprio questo. I Mixins sono una tecnica potente disponibile in C ++ (ma non in Java) e possono darti alcuni degli stessi casi d'uso di un aspetto .

• Fornisci un supporto migliore per gli strumenti : le tecniche come l'utilizzo di grep e l'esecuzione di operazioni di refactoring possono risolvere problemi relativi al codice incrociato. Ad esempio, il nome di un metodo dichiarato in un'interfaccia può tagliare il programma. (Nota la differenza tecnica qui: è il nome del metodo, non dell'implementazione del metodo, che i crosscut.) Questo di solito non è un problema in un IDE come Eclipse, dove puoi usare il "refactoring del rename" per cambiare tutto i posti nel tuo codice che usano il nome. In questo modo, è possibile non aver bisogno di funzionalità linguistiche quando l'ambiente di programmazione è abbastanza espressivo per te.

• Utilizza lingue specifiche del dominio : i primi linguaggi dell'aspetto, che prima di AspectJ, erano specifici del dominio e applicati solo a determinati problemi, come la sincronizzazione dei thread o l'analisi del flusso di dati per combinando efficacemente composizioni di funzioni. Questi linguaggi erano sperimentali, ma sembravano avere molto successo nel modulare le preoccupazioni che altrimenti erano trasversali.

• Utilizza tecniche di programmazione generativa : il passaggio al livello meta potrebbe essere considerato una tecnica di implementazione per la programmazione orientata agli aspetti, ma è un'area abbastanza ampia da trascendere aspetti semplici. Le tecniche generative (in cui un programma genera codice sorgente per un altro programma) sono anche correlate a linguaggi specifici del dominio.

Per tutti questi, penso che studiare AOP sia appropriato. AOP può aiutarti ad espandere le tue concezioni di codice, anche se non utilizzi un linguaggio AOP.

In generale codifica elementi di codice con una funzione dichiarativa, ma specificamente il sistema di attributo nel mondo C # /. NET / Mono.

Non sono un esperto di AOP, ma leggendo su di esso nel corso degli anni, è sempre sembrato una forma più debole del metaprogramming offerto da Lisp , in particolare parti come il suo protocollo metaobject.

Questo non dovrebbe sorprendere, suppongo: Gregor Kiczales è stato uno degli autori di AMOP, e più tardi ha scritto AspectJ per Java!