OOP vs programmazione funzionale vs procedurale [chiusa]

Question

Quali sono le differenze tra questi paradigmi di programmazione, e sono essi più adatti a particolari problemi o fare qualsiasi casi d'uso favoriscono uno sopra gli altri?

esempi di architettura apprezzato!

Answer 1

Tutti sono buoni a modo loro - Sono approcci semplicemente diversi per gli stessi problemi

.

In uno stile puramente procedurale, dati tende ad essere altamente disaccoppiati dalle funzioni che operano su di esso.

In uno stile di oggetto orientato, dati tende a portare con sé un insieme di funzioni.

In uno stile funzionale, i dati e le funzioni tendono verso avere più cose in comune con l'altro (come in Lisp e Scheme), offrendo una maggiore flessibilità in termini di come funzioni vengono effettivamente utilizzati. Algoritmi tendono anche essere definito in termini di ricorsione e composizione anziché loop e iterazione.

Naturalmente, il linguaggio stesso solo influenza che è preferito lo stile. Anche in una lingua pura funzionale come Haskell, è possibile scrivere in uno stile procedurale (anche se questo è altamente sconsigliato), e anche in un linguaggio procedurale come C, è possibile programmare in uno stile orientato agli oggetti (come ad esempio nel GTK + e EFL API).

Per essere chiari, il "vantaggio" di ogni paradigma è semplicemente nella modellazione di algoritmi e strutture dati. Se, ad esempio, l'algoritmo prevede liste e alberi, un algoritmo funzionale può essere la più sensata. Oppure, se, ad esempio, i dati sono altamente strutturata, potrebbe avere più senso per comporre come oggetti se questo è il paradigma nativo della lingua - o, si potrebbe facilmente essere scritto come un'astrazione funzionale di monadi, che è il paradigma originario di linguaggi come Haskell o ML.

La scelta di quale utilizzare è semplicemente ciò che ha più senso per il vostro progetto e le astrazioni supporta la lingua.

Answer 2

Credo che le librerie disponibili, gli strumenti, esempi, e le comunità trionfi completamente il paradigma in questi giorni. Ad esempio, ML (o altro) potrebbe essere l'ultimo di programmazione per tutti gli usi lingua , ma se non è possibile ottenere qualsiasi buone librerie per quello che state facendo sei fregato.

Ad esempio, se stai facendo un videogioco, ci sono esempi di codice più buoni e SDK in C ++, in modo da siete probabilmente meglio con questo. Per una piccola applicazione web, ci sono alcuni grandi quadri Python, PHP e Ruby che ti farti fuori e in esecuzione molto rapidamente. Java è la scelta ideale per grandi progetti a causa della fase di compilazione di controllo e le librerie di impresa e le piattaforme.

E 'usato per essere il caso che le librerie standard per le diverse lingue erano piuttosto piccole e facilmente replicato - C, C ++, Assembler, ML, LISP, ecc .. è venuto con le basi, ma tendevano a far finta di niente quando si trattava di standardizzazione su cose come le comunicazioni di rete, la crittografia, la grafica, i formati di file di dati (tra cui XML), anche le strutture di dati di base come alberi bilanciati e tabelle hash sono stati lasciati fuori!

lingue moderne come Python, PHP, Ruby e Java ora sono dotati di una libreria standard di gran lunga più decente e hanno molte buone librerie di terze parti da poter usare facilmente, grazie in gran parte alla loro adozione di spazi dei nomi da tenere librerie dalla collisione con l'un l'altro, e la raccolta dei rifiuti di standardizzare i sistemi di gestione della memoria delle librerie.

Answer 3

Questi paradigmi non devono escludersi a vicenda. Se si guarda al pitone, supporta funzioni e le classi, ma, allo stesso tempo, ogni cosa è un oggetto, comprese le funzioni. È possibile combinare OOP / stile funzionale / procedurali tutto in un pezzo di codice.

Quello che voglio dire è, in linguaggi funzionali (almeno a Haskell, l'unico che ho studiato) non ci sono dichiarazioni! funzioni sono consentite solo un'espressione al loro interno !! MA, le funzioni sono cittadini di prima classe, è possibile passare in giro come parametri, insieme con un gruppo di altre abilità. Possono fare cose potenti con poche righe di codice.

Mentre in un linguaggio procedurale come C, l'unico modo è possibile passare funzioni intorno è quello di utilizzare puntatori a funzione, e che da solo non consente molte attività potenti.

In Python, una funzione è un cittadino di prima classe, ma può contenere numero arbitrario di dichiarazioni. Così si può avere una funzione che contiene il codice di procedura, ma è possibile passare in giro proprio come i linguaggi funzionali.

Lo stesso vale per OOP. Un linguaggio come Java non consente di scrivere procedure / funzioni al di fuori di una classe. L'unico modo per passare una funzione spostarsi è avvolgerla in un oggetto che implementa tale funzione, e quindi passare tale oggetto intorno.

In Python, non si dispone di questa restrizione.

Answer 4

Per GUI direi che il Paradigma orientato agli oggetti è molto adatto. La finestra è un oggetto, le caselle di testo sono oggetti, e l'accordo-Button è uno di troppo. D'altra roba a mano come di elaborazione delle stringhe può essere fatto con molto meno spese generali e quindi più semplice con una semplice paradigma procedurale.

Non credo che si tratta di una questione della lingua nessuno dei due. È possibile scrivere funzionali, quasi tutte le lingue popolari procedurale o orientata agli oggetti in, anche se potrebbe essere un po 'di sforzo supplementare in alcuni.

Answer 5

Al fine di rispondere alla tua domanda, abbiamo bisogno di due elementi:

1. La comprensione delle caratteristiche dei diversi stili di architettura / modelli.
2. La comprensione delle caratteristiche dei diversi paradigmi di programmazione.

Un elenco di software di architettura stili / modello è indicato sul architettura articolo su Wikipeida. E è possibile la ricerca su di loro facilmente sul web.

In breve e generale, procedurale è buono per un modello che segue una procedura, OOP è buona per la progettazione e funzionale è un bene per la programmazione ad alto livello.

Credo che si dovrebbe provare a leggere la storia su ogni paradigma e capire perché le persone creano e si può capirli facilmente.

Dopo aver capito entrambi, è possibile collegare gli elementi di architettura stili / modelli di paradigmi di programmazione.

Answer 6

Credo che spesso non sono "contro", ma è possibile combinarli. Penso anche che spesso, le parole di cui parli sono solo parole d'ordine. Ci sono poche persone che realmente sanno cosa significa "object-oriented", anche se sono gli evangelisti più feroci di esso.

Answer 7

Uno dei miei amici sta scrivendo un'applicazione grafica utilizzando NVIDIA CUDA . Applicazione adatta molto bene con OOP paradigma e il problema può essere scomposto in moduli ordinatamente. Tuttavia, per utilizzare CUDA è necessario utilizzare C, che non supporta eredità . Pertanto, è necessario essere intelligenti.

a) a elaborare un sistema intelligente, che emulerà eredità in una certa misura. Si può fare!

i) È possibile utilizzare un sistema di ganci, che si aspetta che ogni bambino C del genitore P avere una certa override per la funzione F. È possibile rendere i bambini registrano le loro modifiche locali, che saranno memorizzate e richiamate quando necessario.

ii) È possibile utilizzare struct caratteristica di gettare i bambini in genitori.

Questo può essere pulito, ma non è facile a venire con prova di futuro, soluzione affidabile. Vi permetterà di trascorrere un sacco di tempo la progettazione del sistema e non v'è alcuna garanzia che non si incorrere in problemi a metà strada attraverso il progetto. Implementazione ereditarietà multipla è ancora più difficile, se non quasi impossibile.

b) È possibile utilizzare la politica di denominazione coerente e utilizzare divide et impera approccio per creare un programma. Non avrà alcuna eredità, ma perché le funzioni sono di piccole dimensioni, facile da capire e costantemente formato che non ne ha bisogno. La quantità di codice necessario per scrivere va in su, è molto difficile rimanere concentrato e non soccombere a facili soluzioni (hack). Tuttavia, in questo modo ninja di codifica è il modo C di codifica. Soggiornare in equilibrio tra la libertà di basso livello e scrivere buon codice. Buon modo per raggiungere questo obiettivo è quello di scrivere prototipi utilizzando un linguaggio funzionale. Ad esempio, Haskell è estremamente buono per gli algoritmi di prototipazione.

Io tendo verso approccio b. Ho scritto una possibile soluzione utilizzando l'approccio di una, e sarò onesto, si sentiva molto innaturale utilizzando tale codice.