Morte della tecnologia OOP [chiusa]

9

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?

    
posta Dehumanizer 29.06.2011 - 10:37
fonte

8 risposte

40

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.

    
risposta data 29.06.2011 - 12:05
fonte
20

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.

    
risposta data 29.06.2011 - 10:58
fonte
11

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 data 29.06.2011 - 16:12
fonte
8

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.

    
risposta data 29.06.2011 - 10:55
fonte
6

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.

    
risposta data 30.06.2011 - 16:05
fonte
5

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.

    
risposta data 30.06.2011 - 15:24
fonte
1

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.

    
risposta data 29.06.2011 - 16:21
fonte
0

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.

link

(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.

    
risposta data 30.06.2011 - 13:18
fonte

Leggi altre domande sui tag