Ho sentito parlare più volte della programmazione orientata all'aspetto, principalmente che è la tecnologia di "prossima generazione" in programmazione e sta per "uccidere" OOP.
È giusto? OOP sta per morire o quale può essere la ragione?
OOP technology death [chiuso]
Risposte:
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) è composto da una varietà di specie ampiamente diverse.
Ciò significa che qualsiasi nuova tecnologia avanzata passerà attraverso la curva dell'hype e alla fine troverà il suo scopo specifico nel tempo e nell'esperienza con esso.
Ciò significa anche che un concetto così estremo come la programmazione orientata all'aspetto è utile se è necessario, vale a dire, non sempre e non molto spesso, a causa dei costi impliciti.
Ma ha già il suo posto, come OOProgramming, come la programmazione generica, come la programmazione funzionale, come la programmazione procedurale, ecc.
Hai notato che le lingue più utilizzate (e controverse popolari) e ampiamente diffuse nella vita reale sono "non pure"? Questo perché consentire diversi paradigmi li rende più flessibili al cambiamento di contesto nel tempo e riempiono più nicchie di utilizzo.
1
+1 per "non puro". Linguaggi OOP puri sono notevolmente morti, tranne che per molto di nicchia usi / accademici.
—
jv42,
Cosa considereremmo un linguaggio OO puro? Smalltalk?
—
Zhehao Mao,
OOP non morirà a causa di AOP. AOP aggiunge un certo valore, ma vive in perfetta coesistenza con OOP. Non penso che neanche la programmazione funzionale ucciderà OOP. OOP è troppo adatto per molti tipi di domini problematici, non avrebbe senso sostituirlo con il paradigma funzionale.
È altamente soggettivo. Non penso che OOP sia adatto a un dominio specifico del problema, è adatto a come uno specifico sviluppatore fa una soluzione. OOP non morirà perché gli sviluppatori non possono fare cambi di paradigma.
—
Raynos,
L'esempio classico in cui OOP si adatta bene sono le GUI. È difficile immaginare un'API per un toolkit GUI che non sia OO, anche se la lingua non lo è. (Certo, non è di solito usato il termine dominio problematico) Per dare un esempio di un vero dominio problematico in cui OOP si adatta bene: automazione del magazzino. Modellare i veicoli di stoccaggio e recupero e le loro attività è dove OOP si sente come una scelta naturale.
—
user281377
@ammoQ, le GUI sono orribili quando espresse in OO. Questo è il motivo per cui tutte le API si stanno spostando verso DSL (WPF e simili). Non è difficile immaginare, ad esempio, Tk - nessuna traccia di OOP lì, ma è comunque eccezionale (per la programmazione, non per il suo aspetto grafico), molto meglio di qualsiasi dei toolkit Java OO esagerati. OOP si adatta davvero bene a qualsiasi simulazione basata su agente (come quelle che hai elencato), ma è una piccola parte dei problemi esistenti.
—
SK-logic,
Guardando i primi esempi di tk che ho trovato, come mai non è OO? Dal tutorial: "I widget sono oggetti, istanze di classi che rappresentano pulsanti, cornici e così via". tkdocs.com/tutorial/concepts.html Ancora di più, gli stessi DSL fanno molto affidamento sulla programmazione OO. Quindi non capisco davvero cosa stai cercando di dire?
—
Inca,
@ Sk-logic, @ammoQ, @Raynos, @jkocking, l'ho promosso in una domanda a sé stante: programmers.stackexchange.com/questions/88385/… Sarei molto interessato ad avere ulteriori spiegazioni al riguardo, sono molto interessato a imparare.
—
Inca,
Risposta breve: No, non credo.
Risposta più lunga: da quello che capisco di AOP, non è un paradigma di programmazione in sé (come in, non sostituisce OOP), ma più di un'aggiunta, un kit di strumenti che ti aiuta a scrivere metodi più brevi, classi più semplici, a responsabilità singola , eccetera. Ma non sostituisce OOP.
La cosa che (almeno in parte) sostituisce o aggiunge a OOP è la programmazione funzionale, che in realtà è un diverso paradigma di programmazione (sebbene possa essere mescolato con OOP, ad esempio nel linguaggio di programmazione Scala ). Preferisce strutture dati immutabili e tutti i tipi di funzionalità fantasiose che tendono a frustrare gli sviluppatori OOP, in particolare quando si tratta di concorrenza.
Funzionale <-> Imperativo è la linea. OOP è parallelo ad esso. Penso che la procedura sia all'altra estremità di OOP ma non ne sono sicuro. Naturalmente è divertente che il paradigma funzionale sia più vecchio del paradigma OOP :)
—
Raynos,
@Raynos, non esiste una linea retta. OOP è solo una piccola astrazione metalinguistica all'interno di un enorme (infinito) insieme di possibili linguaggi astratti. E ovviamente è estremamente stupido limitarsi a nessuno di loro.
—
SK-logic,
Oggi si parla di OOP di meno, poiché si presume che sia l'approccio di fatto in molte situazioni. AOP non è mai decollato da nessun tipo di movimento di massa.
Ricordo di aver sentito parlare della programmazione orientata agli aspetti per la prima volta in un tutorial OOPSLA '97. Dissero che avrebbe ucciso OO a quei tempi. Da allora, OO è cresciuto solo oltre le aspettative più sfrenate. AOP, è ancora a malapena noto, essenzialmente senza alcun impatto sul settore informatico. 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 tu abbia i tuoi metodi definiti su una classe. Castle Windsor lo supporta in C #, che è un linguaggio orientato agli oggetti.
Teoricamente potresti passare da OOP a programmazione strutturata e mantenere comunque AOP, ma in pratica sarebbe difficile. È facile sottoclassare qualcosa, sovrascrivere il metodo pertinente per chiamare i filtri prima / dopo appropriati e trasmetterlo nel processo di iniezione di dipendenza.
In confronto, è molto difficile riscrivere le chiamate ai metodi statici per instradare verso un metodo a trampolino progettato per chiamare i filtri definiti dall'utente.
Quindi da un punto di vista dell'implementazione comune, AOP richiede OOP.
Mentre OOP non è certamente un proiettile d'argento, lo stesso si può dire per AOP. Supporta la progettazione basata su componenti, tuttavia nello schema più grande i tuoi componenti sono i nuovi oggetti e le interfacce dei componenti sono fondamentalmente un elenco transazionale di metodi, che NON è vero OOP.
Ulteriori design AOP e basati su componenti supportano un modello di dati anemici, di cui le persone più intelligenti di me criticano.
http://martinfowler.com/bliki/AnemicDomainModel.html
(So che l'articolo sopra è vecchio, ma sorprendentemente rilevante)
La linea di fondo è che i sistemi AOP sono qui per restare ma sono anche lontani dall'essere perfetti. Nessun sistema è perfetto.