AOP ... Dovrei disimparare OOP?

Question

ho scremato la documentazione in linea, leggere la voce wiki, i post e blog, ma sono ancora perplesso.

• Qual è, in estrema sintesi, Aspect Oriented Programming
• E 'semplicemente meglio di Object Oriented Programming? Dovrei disimparare OOP?
• Se no, come faccio a sapere quando usare uno o l'altro? Quali sono le principali differenze tra i due?
• Posso refact l'uno nell'altro?

Sono sempre stato un uomo OO e voglio sapere se ho bisogno di commettere un tradimento.

Scherzi a parte, sto iniziando un nuovo progetto a breve e voglio fare le scelte giuste, all'inizio.

Answer 1

Programmazione Che cosa è, in estrema sintesi, Aspect Oriented?

In poche parole, AOP è la capacità di iniettare azioni nel tipico flusso di un altro programma, discreto. Esso consente di catturare istanze di classe, chiamate di metodo, le assegnazioni, ecc.

E 'semplicemente meglio di programmazione orientata agli oggetti? Dovrei disimparare OOP?

No, e no. Funziona con qualsiasi ambiente di programmazione che lo supporta. (Vedi sopra).

Se no, come faccio a sapere quando usare uno o l'altro? Quali sono le principali differenze tra i due?

Si utilizza AOP, in generale, quando si vuole attuare una sorta di azioni su centinaia di classi, senza manipolare le classi stesse. Esempi tipici sono la sicurezza (autorizzazione della facoltà di richiedere al dato metodo / classe) o di registrazione. Nella mia esperienza, però, io non lo uso per questo. (Io non lo uso a tutti, onestamente).

Come sopra, la differenza principale realtà non esiste, in quanto non sono comparabili. Ma, diciamo che si desidera implementare la registrazione "normalmente", basta chiamare il logger in punti appropriati:

log.write("hello");

Ma con AOP, si può creare un 'aspetto' che si attacca ad ogni chiamata di metodo, e log 'Metodo b chiamato'. Il punto è che in AOP si approccio è più 'fucile': si collega a tutto, o solo un piccolo sottoinsieme. Aggiunta manuale di registrazione è generalmente migliore.

Posso refact l'uno nell'altro?

Non è davvero rilevante, vedere altre risposte. Anche in questo caso con la sicurezza, si potrebbe scambiare per un modello AOP da un tipico modello OOP this.IsAllowed () a qualcosa come se (callingMethod.HasAttribute (foo)) {permesso = true; }

La speranza quelle risposte sono utili. Fammi sapere se vuoi che espandere ulteriormente.

Answer 2

No, AOP OOP complementare, piuttosto che soppiantando esso. AOP e OOP fornire diversi tipi di "collante" per aiutare a combinare i comportamenti. OOP, naturalmente, permette di combinare il comportamento attraverso l'eredità e la composizione, ecc AOP d'altra parte consente di aggiungere un comportamento per affrontare preoccupazioni di taglio trasversale intercettando in cui il nuovo codice corre prima o dopo i metodi scelti delle classi selezionate.

Alcuni esempi comuni di preoccupazioni trasversali sono: la sicurezza, la registrazione e il controllo delle transazioni. Un principio fondamentale del buon design è la coerenza: idealmente, un pezzo di codice dovrebbe fare solo una cosa. Così intorbida l'acqua per aggiungere codice di sicurezza per le classi di accesso ai dati, per esempio. AOP risolve questo problema particolare consentendo di aggiungere il comportamento in un "Aspetto" e poi applicare questo aspetto a tutte le classi che dovrebbero avere i controlli di sicurezza.

Answer 3

AOP è diverso da OOP, completamente diversi approcci allo sviluppo.

In sostanza, se avete la registrazione, le preoccupazioni di autenticazione, il codice di controllo delle prestazioni, questi saranno gli stessi, più o meno, in varie parti del programma, in diverse classi. Quindi, è possibile scrivere l'applicazione come immaginate che, in Java, poi, quando è necessario aggiungere a questi altri tipi di codice (preoccupazioni trasversali), allora semplicemente iniettare nel programma, in modo che possano essere compilati in, ma quando si guarda il codice sorgente, basta vedere la logica di business non è necessario.

Per quanto riguarda quando usare AOP o OOP, vorrei suggerire che si scrive il programma, farlo funzionare, poi quando lo avete funzionante, guarda a rimuovere il codice che in realtà non hanno a che fare con la funzione, ma serve un po ' altro scopo. Ad esempio, se è necessario controllare che i parametri di input siano corretti prima di utilizzarli, quindi utilizzare un aspetto per questo. Se si dispone di gestione degli eventi simili, come ad esempio tutte le eccezioni generate nello strato di accesso ai dati scrive un file di log, quindi creare un aspetto per questo.

Come si rimuove questi trasversale riguarda il codice otterrà più piccolo.

Come si ottiene più esperienza si vedrà più usi per AOP, ma inizialmente vorrei suggerire di scrittura, quindi refactoring con AOP.

Usa Eclipse, se si utilizza Java, per AOP, come il plugin AJDT sarà molto utile per vedere dove si sta aggiungendo aspetti.

Answer 4

Aspect-Oriented Programming è una parola d'ordine accattivante per l'inserimento di azioni (chiamati "consigli") in metodi o funzioni in punti chiave come le chiamate e ritorni, tra gli altri. Ho un grosso problema con AOP perché viola tutte le barriere di astrazione integrate nel linguaggio. Non c'è modo per un modulo a dire "questo è ciò che un aspetto può pasticciare con e questo è ciò che un aspetto non possono pasticciare con." Di conseguenza, si rischia di violare invarianti interne, e si distrugge il principio di ragionamento modulare (si può capire un modulo, senza dover capire nulla, ma le interfacce degli altri moduli che importa).

Alcuni anni fa Raymie Stata ha scritto una tesi di dottorato brillante su come linguaggi orientati agli oggetti potrebbero controllare subclassing e impedirgli di violare invarianti chiave. Il lavoro di corrispondente per l'AOP deve ancora essere scritta.

Mentre come con qualsiasi altra idea che i guadagni di valuta, AOP ha goduto di alcuni successi spettacolari (ad esempio, retrofitting registrazione a un'applicazione non progettati con la registrazione in mente), nel complesso io vi esorto a limitare l'uso di AOP casi molto semplici . O meglio ancora, basta dire no alla programmazione orientata agli aspetti.

Answer 5

Letture consigliate: Eclipse AspectJ: Aspect-Oriented Programming con AspectJ e lo sviluppo Eclipse AspectJ Strumenti