Ho sentito molte volte la programmazione orientata agli aspetti, principalmente che è la tecnologia di "prossima generazione" nella programmazione e sta per "uccidere" l'OOP.
È giusto? OOP sta per morire o quale può essere la ragione?
Ho sentito molte volte la programmazione orientata agli aspetti, principalmente che è la tecnologia di "prossima generazione" nella programmazione e sta per "uccidere" l'OOP.
È giusto? OOP sta per morire o quale può essere la ragione?
Ogni volta che qualcuno ti dice che una tecnologia software ne ucciderà un'altra o dominerà l'intero mercato / uso / pubblico, ricorda questo:
Un ecosistema sano (dinamico ma stabile) è costituito da una varietà di specie molto diverse.
Ciò significa che qualsiasi nuova tecnologia hyped passerà attraverso la curva di hype e alla fine troverà che è specifica (s ) scopo nel tempo ed esperienza con esso.
Ciòsignificaanchecheunconcettocosìestremocomelaprogrammazioneorientataagliaspettièutileseènecessario,ovverononsempreenonmoltospessoacausadeicostiimpliciti.
Mahagiàilsuoposto,comeOOProgramming,comelaprogrammazionegenerica,comelaprogrammazionefunzionale,comelaprogrammazioneprocedurale,ecc.
Hainotatocheilinguaggipiùutilizzati(epolemicamentepopolari)eampiamentediffusinellavitarealesono"non puri"? Questo perché consentire diversi paradigmi li rende più flessibili nei cambi di contesto nel tempo e riempiono più nicchie di utilizzo.
OOP non morirà a causa di AOP. AOP aggiunge un certo valore, ma vive in perfetta coesistenza con OOP. Neanche io penso che la programmazione funzionale possa uccidere OOP. OOP è troppo adatto per molti tipi di domini problematici, non avrebbe senso sostituirlo con il paradigma funzionale.
I paradigmi vanno e vengono, ma il codice legacy è per sempre. Ci sarà sempre un codice C ++ da mantenere, quindi OOP non morirà mai completamente.
Risposta breve: no, non la penso così
Risposta più lunga: da quello che ho capito di AOP, non è un paradigma di programmazione in sé (come in, non sostituisce OOP), ma più un'aggiunta, un toolkit che ti aiuta a scrivere metodi più brevi, più semplici, singoli -le classi di responsabilità, eccetera. Ma non sostituisce OOP.
La cosa che (almeno in parte) sostituisce o aggiunge a OOP è la programmazione funzionale, che in realtà è un paradigma di programmazione diverso (sebbene possa essere combinato con OOP, ad esempio in il linguaggio di programmazione di Scala ). Preferisce le strutture immutabili e tutti i tipi di caratteristiche fantasiose che tendono a frustrare gli sviluppatori OOP, in particolare quando si tratta di concorrenza.
OOP si parla di meno in questi giorni dal momento che si presume che sia l'approccio di fatto in molte situazioni. AOP non è mai decollato come nessun tipo di movimento di massa.
Ricordo di aver sentito parlare di Aspect Oriented Programming seduto per la prima volta in un tutorial di OOPSLA '97. Hanno detto che avrebbe poi ucciso OO. Da allora, OO è cresciuta solo oltre le più rosee aspettative. AOP, è ancora poco conosciuto con praticamente nessun impatto sull'industria informatica. Penso che la risposta sia ovvia che AOP non è un killer OO.
Guarda alcuni sistemi AOP esistenti. Dipendono dal fatto che tu abbia del codice scritto in qualche modo - ad esempio, Spring AOP si basa sul fatto che hai definito i tuoi metodi su una classe. Castle Windsor lo supporta in C #, che è un linguaggio orientato agli oggetti.
Potresti teoricamente passare da OOP a programmazione strutturata e mantenere comunque AOP, ma in pratica sarebbe difficile. È facile creare una sottoclasse di qualcosa, scavalcare il metodo pertinente per chiamare i filtri appropriati prima / dopo e inoltrarlo nel processo di inserimento delle dipendenze.
È dannatamente difficile rispetto a riscrivere le chiamate al metodo statico per instradare a un metodo di trampolino progettato per chiamare i filtri definiti dall'utente.
Quindi, da un punto di vista di implementazione comune, AOP richiede OOP.
Mentre OOP non è certamente un proiettile d'argento, lo stesso si può dire per AOP. Supporta la progettazione basata sui componenti, tuttavia nello schema di grander i componenti sono i nuovi oggetti e le interfacce dei componenti sono fondamentalmente un elenco transazionale di metodi, che NON è vero OOP.
Ulteriori AOP e progettazione basata su componenti supportano un Anemic Data Model, a cui sono più critiche le persone più intelligenti di me.
(So che l'articolo sopra è vecchio, ma sorprendentemente pertinente)
La linea di fondo è che i sistemi AOP sono qui per rimanere ma sono tutt'altro che perfetti. Nessun sistema è perfetto.
Leggi altre domande sui tag object-oriented