La programmazione orientata all'aspetto è impropria?

Penso che questo sia davvero un problema perché la definizione di una "metodologia" e "paradigma" e "programmazione orientata" è potenzialmente un po 'sciolta in questo contesto, ma giocherò con l'avvocato del diavolo e andrò con " sì, è un termine improprio ".

Anche se non hai utilizzato le funzionalità AOP o AOP per risolvere un problema, starai ancora pensando a quegli aspetti - potresti averli scritti come documentazione da qualche parte, o potresti usare un generatore di codice - in entrambi i casi , il concetto di aspetti è ancora lì. Questo potrebbe anche andare con qualsiasi paradigma; anche se sarebbe abbastanza brutto, potresti comunque fare OOP in C.

Quindi questo non significa che AOP sia una metodologia tanto quanto lo è OOP? Penso che ci sia dell'altro.

Il motivo è che una metodologia offre una soluzione a un particolare tipo di problema . Non si utilizzano più di una metodologia per risolvere un problema concettuale, anche se è possibile utilizzarne due o più nello schema più grande. È possibile utilizzare OOP e procedurale per scrivere un'interfaccia utente di data entry, ma si utilizza solo OOP per descrivere la struttura astratta dell'interfaccia utente e si stanno solo utilizzando procedure (più accuratamente, metodi) per descrivere il suo comportamento. Tra i componenti costitutivi di un problema, le metodologie si escludono a vicenda - e AOP può ancora prendere parte alla risoluzione di un problema con codice funzionale, OOP o procedurale.

AOP risolve i problemi nel senso che riduce la quantità di codice ripetuto, ma è ben compreso nella descrizione del lavoro di una funzione linguistica. Non hai davvero risolto concettualmente alcun problema vero dicendo che otterrai il compilatore o il runtime per iniettare del codice che non dovevi scrivere esplicitamente; hai appena reso il tuo codice un po 'più organizzato. Dichiarare che "tutte le mie funzioni registreranno i loro orari di inizio e fine" non è una soluzione a un problema; è solo una dichiarazione di un problema.

Penso che sarebbe più appropriato per loro essere chiamati semplicemente "Aspetti", come caratteristica del linguaggio.

Tutte le metodologie di sviluppo sono solo modi di pensare all'organizzazione del codice. Ogni metodologia di sviluppo può produrre codice dall'aspetto molto diverso, oppure possono produrre codice simile. Possono anche richiedere librerie o funzionalità linguistiche per il supporto.

In C ++, ad esempio, AOP viene in genere implementato utilizzando le classi di caratteri e il polimorfismo in fase di compilazione. Non è affatto una "caratteristica" linguistica: costruisci i vari aspetti del tuo tipo e li combini come preferisci con i modelli.

In linguaggi come Java che non hanno qualcosa come i template, finisci per dover utilizzare le funzionalità linguistiche dedicate fornite dai preprocessori (ad esempio AspectJ ) per programmare in modo orientato all'aspetto, semplicemente perché la lingua originale non ha la capacità di implementare il vero AOP stesso.

Di conseguenza, i programmi AOP appariranno molto diversi in C ++ rispetto a Java - ma ciò che è più importante è il modo in cui il programmatore sta pensando sul suo design, non su come appare il codice .

Pertanto, l'AOP è certamente una metodologia di sviluppo.

Ci sono due cose in gioco qui - paradigma di programmazione contro metodologia di sviluppo del software .

Sì, la programmazione orientata agli aspetti è un paradigma di programmazione. Sfrutta alcune funzionalità linguistiche per rappresentare i costrutti necessari per svolgere un'attività o per rendere il codice più leggibile. È una tecnica che può essere utilizzata da un programmatore. Un sacco di volte, si vede AOP utilizzato insieme alla programmazione orientata agli oggetti per rimuovere i problemi trasversali. Tuttavia, puoi implementare programmazione orientata all'aspetto anche in un linguaggio funzionale . Non è necessariamente un paradigma del tutto nuovo, ma un'estensione all'OOP e alla programmazione funzionale per alleviare i problemi noti. Il motivo principale per cui credo che dovrebbe essere considerato un paradigma è che cambia il modo in cui pensi di raggiungere una soluzione al problema. Proprio come la programmazione funzionale, la programmazione procedurale, la programmazione logica e la programmazione orientata agli oggetti hanno tutte soluzioni drasticamente diverse per lo stesso problema, la programmazione orientata all'aspetto aggiunge un'altra soluzione al problema.

No, la programmazione orientata agli aspetti non è una metodologia di sviluppo. Una metodologia di sviluppo è un framework che è possibile utilizzare per creare un sistema software. Specifica quali compiti eseguire e come li svolgi, dai requisiti fino alla fine del ciclo di vita. AOP non dice nulla a riguardo. Tuttavia, alcuni paradigmi di programmazione hanno portato a approcci metodologici di sviluppo per il ciclo di vita del software. C'era un approccio chiamato Ingegneria software orientata agli oggetti, sviluppata da Ivar Jacobson che ha specificato un ciclo di vita completo per la progettazione e lo sviluppo di sistemi orientati agli oggetti, ma è caduto in disgrazia ed è stato sostituito da UML e Rational Unified Process. Onestamente non vedo le metodologie influenzanti AOP allo stesso modo di OOP. In effetti, il solo guardare alle tendenze sembra indicare che le metodologie dovrebbero trascendere il linguaggio e i paradigmi usati per costruire il software. Ci potrebbero essere tecniche di modellazione e vocabolario orientate alla AOP utilizzate durante la progettazione e lo sviluppo, ma non vedo una metodologia completa centrata su AOP.