it-swarm.it

OOP soddisfa la promessa di riutilizzo del codice? Quali alternative ci sono per ottenere il riutilizzo del codice?

Forse la più grande promessa di usare il paradigma orientato agli oggetti è il riutilizzo del codice. Alcuni contestano che ciò sia stato raggiunto. Perché è stato (non) raggiunto?

Il codice viene riutilizzato come OOP lo definisce, rende i progetti più produttivi?

O più gestibile? O più facile da mantenere? O con più qualità?

Probabilmente siamo tutti d'accordo sul fatto che il riutilizzo del codice sia una buona cosa, ma ci sono diversi modi per raggiungere questo obiettivo. La domanda riguarda il metodo di riutilizzo del codice offerto da OOP. È stata una buona cosa? Esistono metodi migliori per ottenere il riutilizzo del codice rispetto all'orientamento agli oggetti, alla sottoclasse, al polimorfismo, ecc.? Quali sono i modi migliori? Perché?

Raccontaci la tua esperienza con OOP o riutilizzo di altri paradigmi.

56
Maniero

Il riutilizzo del codice è una buona idea. Non eccezionale.

Ho una prospettiva tratta da circa 30 anni di ingegneria del software, cercando di "riutilizzare".

Ho iniziato a studiare il "riutilizzo del codice" come argomento di ricerca negli anni '80, dopo aver scoperto di aver riutilizzato la progettazione di un sistema operativo che ho creato nei primi anni '70, per un altro sistema operativo che ho costruito alla fine degli anni '70.

La buona parte del riutilizzo del codice è la possibilità di riutilizzare a volte il codice preesistente da onesto a dio. Ma il mondo è pieno di codice; come puoi trovare quello che vuoi? Ecco cosa chiamo il Reuse Curse :

Sono Babbo Natale (ok Open Source) e ho un sacco di 1 miliardo di componenti software. Puoi averne uno qualsiasi.

Buona fortuna a scegliere.

Per risolvere bene il problema del riutilizzo:

  • il riutilizzatore deve in qualche modo specificare ciò di cui ha bisogno (funzionalità, prestazioni, lingua di destinazione, ipotesi ambientali, ...)
  • ci deve essere una libreria di codice "riutilizzabile" che è stata indicizzata in vari modi da questi criteri potenziali
  • deve esistere un meccanismo per selezionare gli elementi candidati (con un miliardo di elementi, non è possibile esaminarli tutti personalmente)
  • deve esserci un modo per caratterizzare quanto siano lontani dalle specifiche i candidati scelti
  • dovrebbe esistere un processo regolare per consentire al riutilizzatore di modificare il codice riutilizzabile scelto (ecco il maggior contributo di OOP: è possibile modificare un componente/oggetto esistente sovrascrivendo i suoi slot. OOP non fornisce alcun altro aiuto).
  • tutto ciò deve chiaramente essere più economico della semplice ricodifica

Principalmente ciò che è stato scoperto nel corso degli anni è che per essere riutilizzabile, il codice deve essere progettato a tale scopo o contiene troppe ipotesi implicite. Le librerie di riutilizzo del codice di maggior successo sono state in realtà piuttosto piccole. Probabilmente librerie e framework sono codici "riutilizzabili" e hanno un enorme successo; Java e C # non riescono perché sono linguaggi informatici piuttosto buoni, ma piuttosto perché hanno enormi librerie ben progettate, implementate e documentate disponibili. Ma le persone non guardano il codice sorgente nel librerie; chiamano semplicemente un'API ben documentata (progettata per essere generalmente utilizzabile).

Ciò che il riutilizzo del codice non ha fatto (né OOP) è fornire ordini di miglioramento della grandezza nella nostra capacità di codificare i sistemi.

Penso che il difetto chiave sia che qualsiasi tipo di riutilizzo del codice è sostanzialmente limitato perché il codice ha troppe ipotesi incorporate . Se rendi il codice minuscolo, riduci al minimo le ipotesi, ma poi il costo per creare da zero non è molto grande e i guadagni di riutilizzo non sono efficaci. Se rendi enormi i blocchi di codice, sono praticamente inutili in un nuovo contesto. Come Gulliver, sono legati alla spiaggia da un milione di minuscole stringhe e semplicemente non puoi permetterti di tagliarle tutte.

Ciò su cui dovremmo lavorare è riutilizzo delle conoscenze per costruire il codice . Se riusciamo a farlo, allora possiamo applicare quella conoscenza per costruire il codice di cui abbiamo bisogno, gestendo l'attuale insieme di ipotesi.

Per fare ciò, è ancora necessaria la stessa capacità di specifica per caratterizzare i componenti del software (devi ancora dire quello che vuoi!). Ma poi applichi questa conoscenza di "costruzione" alle specifiche per genera il codice che desideri.

Come comunità, non siamo ancora molto bravi in ​​questo. Ma la gente lo fa sempre; perché non possiamo automatizzarlo? C'è molta ricerca, e questo dimostra che può essere fatto in molte circostanze.

Un pezzo chiave del macchinario necessario per questo sono strumenti meccanici per accettare "descrizioni dei componenti" (questi sono solo documenti formali e possono essere analizzati come linguaggi di programmazione) e applicare trasformazioni di programma = a loro.

I compilatori lo fanno già: -} E sono davvero bravi nella classe di problemi che affrontano.

I modelli UML con generazione di codice sono un tentativo per farlo. Non è un ottimo tentativo; praticamente quello che si dice nella maggior parte dei modelli UML è "Ho dati che assomigliano a questo". Abbastanza difficile generare un vero programma se la funzionalità viene lasciata fuori.

Sto cercando di costruire pratici sistemi di trasformazione del programma, uno strumento chiamato DMS . Sono stato abbastanza distratto dall'applicazione delle trasformazioni del programma non tanto alle specifiche astratte per generare il codice, ma piuttosto al codice legacy per ripulirlo. (Questi sono gli stessi problemi in astratto!). (Per costruire tali strumenti richiede molto tempo; lo faccio da 15 anni e nel frattempo devi mangiare).

Ma DMS ha le due proprietà chiave che ho descritto sopra: la capacità di elaborare specifiche formali arbitrarie e la capacità di acquisire "conoscenze sulla generazione di codice" come trasformazioni e applicarle su richiesta. E sorprendentemente, generiamo in alcuni casi speciali, un codice piuttosto interessante dalle specifiche; DMS è in gran parte costruito usando se stesso per generare la sua implementazione. Ciò ha raggiunto per noi almeno alcune delle promesse di riutilizzo (della conoscenza): incrementi di produttività estremamente significativi. Ho un team di circa 7 persone tecniche; abbiamo probabilmente scritto 1-2 MSLOC di "specifiche" per DMS, ma abbiamo circa 10 MSLOC di codice generato.

Riepilogo: riutilizzo delle conoscenze sulla generazione è la vittoria, non riutilizzo del codice.

35
Ira Baxter

Il riutilizzo del codice si ottiene in OOP ma si ottiene anche nella programmazione funzionale. Ogni volta che si prende un blocco di codice e lo si rende richiamabile dal resto del codice in modo da poter utilizzare questa funzionalità altrove è il riutilizzo del codice.

Questo tipo di riutilizzo del codice rende anche il codice più gestibile perché la modifica di questo blocco richiamabile modifica tutte le posizioni in cui viene chiamato. Direi che anche questo risultato ha migliorato la qualità e la leggibilità.

Non sono sicuro OOP è semplicemente lì per fornire il riutilizzo del codice. Guardo OOP come più di un modo per interagire con gli oggetti e sottrarre i dettagli di la struttura dei dati.

Da Wikpedia:

La programmazione orientata agli oggetti ha radici che possono essere fatte risalire agli anni '60. Man mano che l'hardware e il software diventano sempre più complessi, la gestibilità diventa spesso una preoccupazione. I ricercatori hanno studiato i modi per mantenere la qualità del software e hanno sviluppato una programmazione orientata agli oggetti in parte per affrontare i problemi comuni enfatizzando fortemente le unità discrete e riutilizzabili della logica di programmazione [citazione necessaria]. La tecnologia si concentra sui dati piuttosto che sui processi, con programmi composti da moduli autosufficienti ("classi"), ciascuna delle quali ("oggetti") contiene tutte le informazioni necessarie per manipolare la propria struttura di dati ("membri"). Ciò è in contrasto con la programmazione modulare esistente che era stata dominante per molti anni che si concentrava sulla funzione di un modulo, piuttosto che specificamente sui dati, ma prevedeva ugualmente il riutilizzo del codice e unità riutilizzabili autosufficienti della logica di programmazione, consentendo la collaborazione attraverso l'uso di moduli collegati (subroutine). Questo approccio più convenzionale, che persiste ancora, tende a considerare i dati e il comportamento separatamente.

36
Chris

Sì e No

Il riutilizzo del codice è un termine generico per molte attività diverse.

  1. Riutilizzo del codice all'interno di un singolo progetto. OO è perfettamente adatto a questo, un'applicazione ben progettata avrà mappato da vicino le relazioni del mondo modellato, eliminando così il codice duplicato il più possibile e consigliabile. Tuttavia, puoi sostenere che le tecnologie pre-OO potrebbero ottenere la stessa cosa, il che è vero, ma OO è per molti versi più conveniente.
  2. Librerie di terze parti Questo sembra funzionare ugualmente bene con o senza OO.
  3. Riutilizzo del codice multiuso La più grande promessa di riutilizzo del codice di OO era quel codice, una volta scritto per un'applicazione può essere successivamente riutilizzato per un'altra, che non aveva è stato progettato appositamente per. Questo è stato di gran moda quando il concetto di OO è filtrato attraverso le porte degli uffici di gestione superiore e OO non è riuscito a realizzarlo. Si è scoperto che lo scopo era un aspetto cruciale di OO design (e probabilmente tutto il codice procedurale, ma questa è solo la mia teoria) e i tentativi di riproporre il codice si sono conclusi con disastri di manutenzione. (I noti antipattern di un vecchio framework che nessuno osa modificare e il suo amico, il framework leggermente diverso per ogni app di solito deriva da qui.)
15
biziclop

Sono d'accordo con Chris, la programmazione funzionale è un buon modo per riutilizzare il codice.

Molti programmi hanno strutture di codice ricorrenti. Per questo alcuni modelli di progettazione sono usati nel mondo OOP, ma ciò può essere ottenuto da funzioni ricorsive e pattern matching nei linguaggi di programmazione funzionale. Per ulteriori informazioni, consultare il primo capitolo in Real World Functional Programming .

Penso che l'eredità profonda in OOP può essere fuorviante in molti casi. Hai una classe e molti dei metodi strettamente correlati sono implementati in diversi file. As Joe Armstrong detto su OOP:

Il problema con i linguaggi orientati agli oggetti è che hanno tutto questo ambiente implicito che portano con sé. Volevi una banana, ma quello che hai ottenuto è stato un gorilla con in mano la banana e l'intera giungla.

Le funzioni di ordine elevato sono anche molto utili quando si tratta di riutilizzare il codice, ad es. map e foldr che è la base di Google MapReduce .

Il passaggio di messaggi asincroni è anche un buon modo per organizzare software complessi e alcuni scienziati informatici affermano che si presume che gli oggetti comunichino tra loro asincroni come in Indica, non chiedere OOP. Vedi di più in Programmazione orientata agli oggetti: The Wrong Path? were Joe Armstrong è quotata:

Ho iniziato a chiedermi cosa fosse la programmazione orientata agli oggetti e pensavo che Erlang non fosse orientato agli oggetti, era un linguaggio di programmazione funzionale. Quindi, il mio supervisore della tesi ha detto "Ma ti sbagli, Erlang è estremamente orientato agli oggetti". Ha detto che i linguaggi orientati agli oggetti non sono orientati agli oggetti. Potrei pensare, anche se non sono del tutto sicuro di crederci o no, ma Erlang potrebbe essere l'unico linguaggio orientato agli oggetti perché i 3 principi della programmazione orientata agli oggetti sono che si basa sul messaggio passando , che hai isolamento tra gli oggetti e hai polimorfismo .

Il passaggio di messaggi asincroni come nei sistemi basati sugli eventi e in Erlang è anche un ottimo modo per disaccoppiare i sistemi e l'accoppiamento lento è importante nei sistemi complessi. Con un sistema sufficientemente disaccoppiato è possibile far evolvere il sistema mentre è in esecuzione, magari su nodi diversi. Unibet ha fatto un'ottima presentazione al riguardo: Domain Event Driven Architecture

Tuttavia, penso che la maggior parte del riutilizzo del codice venga eseguita utilizzando librerie e framework.

13
Jonas

Vorrei pubblicare una risposta lunga ma perché? Udi Dahan lo spiega molto meglio di me.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Ecco l'inizio del post:

Questo settore è pre-occupato con il riutilizzo.

C'è questa convinzione che se riutilizzassimo più codice, tutto sarebbe meglio.

Alcuni arrivano addirittura a dire che l'intero punto dell'orientamento agli oggetti è stato riutilizzato - non lo era, l'incapsulamento era la cosa più importante. Dopo che l'orientamento ai componenti era la cosa che doveva far accadere il riutilizzo. Apparentemente non è andato così bene neanche perché qui stiamo riponendo le nostre speranze riutilizzabili sull'orientamento al servizio.

Sono stati scritti interi libri di schemi su come ottenere il riutilizzo con l'orientamento della giornata. I servizi sono stati classificati in tutti i modi nel tentativo di raggiungere questo obiettivo, dai servizi alle entità e ai servizi di attività, attraverso i servizi di processo e i servizi di orchestrazione. I servizi di composizione sono stati pubblicizzati come la chiave per il riutilizzo e la creazione di servizi riutilizzabili.

Potrei anche farti conoscere il piccolo segreto sporco:

Il riutilizzo è un errore

13
Tony

L'umile pipe unix ha fatto di più per il riutilizzo del codice di qualsiasi altra cosa sia andata e venuta. Gli oggetti sono semplicemente diventati un modo intuitivo di strutturare il codice quando sono arrivati ​​e in seguito le persone hanno iniziato a puntare su tutto e tutto. In generale gli oggetti sono per l'incapsulamento e non per il riutilizzo del codice, il riutilizzo del codice richiede qualcosa di più e la gerarchia dell'ereditarietà delle classi è un cattivo sostituto di ciò che dovrebbe essere un meccanismo di riutilizzo del codice.

6
davidk01

OOP non è speciale; puoi creare codice riutilizzabile con o senza OOP. Le funzioni pure sono particolarmente riutilizzabili: ad esempio, Java.lang.math.sqrt(double) accetta un numero e ne fornisce un numero. No OOP, ma sicuramente più riutilizzabile rispetto alla maggior parte dei codici disponibili.

4
Joonas Pulakka

Da una vista di programmazione funzionale OOP riguarda principalmente la gestione dello stato.

Nella programmazione funzionale puoi facilmente avere centinaia di utili funzioni per gli elenchi: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .

Avresti centinaia di metodi in una classe List? I metodi pubblici sono considerati un'interfaccia allo stato interno che si desidera mantenere di dimensioni ridotte.

Purtroppo, invece di (ri) utilizzare molte piccole funzioni, alcune persone duplicano la funzionalità. Per me è perché OOP non incoraggia il riutilizzo del codice tanto quanto la programmazione funzionale.

4
LennyProgrammers

Per me sì, ma non sempre, e avrebbe potuto essere fatto in altri modi.

Il più delle volte creando una classe base astratta e creando implementazioni concrete di quella classe.

Inoltre, molti framework utilizzano l'ereditarietà per fornire il riutilizzo del codice (Delphi, Java, .Net sono solo alcuni di quelli che vengono subito in mente).

Questo non vuol dire che molte librerie di utilità e frammenti di codice non avrebbero potuto fare altrettanto, ma c'è qualcosa di gradito in una gerarchia di oggetti ben progettata.

3
Chris Buckett

Nella mia esperienza, ho avuto più successo sfruttando il codice "riutilizzabile" attraverso strutture di programmazione generiche (come i modelli C++) di quanto abbia avuto usando i principi OOP come le gerarchie ereditarie.

3
Charles Salvia

OOP è troppo aperto per un riutilizzo efficace.

Ci sono troppi modi per riutilizzarli. Ogni classe pubblica chiede: "crea una nuova istanza di me!", ogni metodo pubblico dice: "chiamami!", ogni metodo protetto produce: = "override me!" - e tutti questi modi di riutilizzo sono diversi , hanno parametri diversi, appaiono in diversi contesto, tutti hanno le loro regole diverse, come chiamarlo/estenderlo/sovrascriverlo.

[~ # ~] api [~ # ~] è migliore, è un sottoinsieme rigoroso di OOP (o non -oop) punti, ma nella vita reale le API sono troppo funzionanti e in continua crescita, ci sono ancora troppi punti di connessione. Inoltre, una buona API può semplificare la vita, è il modo migliore per fornire l'interfaccia per OOP.


Il paradigma di Datadlow fornisce un'interfaccia rigorosa per i componenti, hanno porte dei seguenti tipi:

  • consumatori (input) e
  • produttori (risultati).

Dipende dal dominio, ci sono alcuni tipi di pacchetti, quindi i consumatori e i produttori possono essere collegati in quanto hanno porte uguali (o compatibili). La parte più bella di ciò, che può essere eseguita visivamente, poiché non ci sono parametri o altre modifiche sulle connessioni, collegano davvero solo un consumatore e un produttore.

Ero un po 'poco chiaro, potresti dare un'occhiata a tag "flusso di dati" su StackOverflow , oppure Wikipedia "programmazione datafow" o Wikipedia "programmazione basata sul flusso " .

(Inoltre, ho scritto un sistema di flusso di dati, in C++. Quindi OOP e DF non sono nemici, DF è un modo di organizzazione di livello superiore.)

2
ern0

In CommonLisp ci sono molti modi per ottenere il riutilizzo:

  • digitazione dinamica, il cui codice è generico per impostazione predefinita

  • astrazioni imperative, cioè subroutine

  • orientamento dell'oggetto, con eredità multipla e spedizione multipla

  • sintassi-astrazione, la capacità di definire nuovi costrutti sintattici o abbreviare il codice della piastra della caldaia

  • astrazioni funzionali, chiusure e funzioni di alto ordine

Se provi a confrontare l'esperienza CommonLisp con altre lingue vedrai che la principale caratteristica che facilita il riutilizzo del codice è la presenza di entrambi astrazioni orientate agli oggetti e funzionali. Sono più complementari che alternativi: senza uno di essi sei costretto a reimplementare le funzionalità mancanti in modo goffo. Vedere, ad esempio, le classi di funzioni utilizzate come chiusure e corrispondenza dei pattern per ottenere l'invio di metodi non estendibile.

2
Andrea

OOP ti dà altro modi per riutilizzare il codice. Questo è tutto.

1
Steven A. Lowe

In realtà non esiste un "riutilizzo" nel modo in cui le persone lo descrivono. Il riutilizzo è una proprietà accidentale di qualsiasi cosa. È difficile pianificarlo. Ciò che la maggior parte delle persone intende quando parlano di "riutilizzo" è "uso". È un termine molto meno attraente ed eccitante. Quando usi una libreria, la usi per quello a cui era destinata, normalmente. Stai non riutilizzandolo a meno che tu non stia facendo qualcosa di veramente pazzo.

In tal senso, il riutilizzo nel mondo reale riguarda il ri-scopo delle cose. Posso riutilizzare questi posti qui e riordinarli per formare ... un letto! Non è un letto molto comodo, ma posso farlo. Questo non è il loro uso principale. Li sto riutilizzando al di fuori del loro dominio originale di applicabilità. [...] Domani tornerò in aereo nel Regno Unito. non riutilizzerò l'aereo. Lo userò solo per lo scopo a cui era destinato, non c'è niente di speciale o eccitante in questo.

- Kevlin Henney

1
fredoverflow

Riutilizzo orizzontale: aspetti, tratti, innesti

Classico OO a volte non riesce a riutilizzare il codice, specialmente quando impazzisci tutta l'eredità per mancanza di un modo migliore per condividere la funzionalità effettiva tra le classi. Per questo problema, sono stati creati meccanismi di riutilizzo orizzontale, come come AOP, tratti e innesti.

Programmazione orientata agli aspetti

Considero AOP come la mezza arancia mancante di OOP. AOP non è poi così noto, ma è arrivato al codice di produzione.

Lo proverò a spiegare in termini semplici: immagina di poter iniettare e filtrare la funzionalità con una struttura speciale chiamata aspetto, questi aspetti hanno "metodi" che definiscono cosa e come verrà influenzato attraverso riflessione , ma in fase di compilazione, questo processo è chiamato tessitura .

Un esempio potrebbe essere un aspetto che dice "per tutti i metodi di determinate classi che iniziano con get, il programma scriverà in un file di registro i dati che sono stati ottenuti e l'ora in cui sono stati".

Guarda questi due discorsi se vuoi capire meglio AOP:

Tratti e innesti

Tratti sono un altro costrutto per la definizione di codice riutilizzabile che completa OOP, sono simili a mixins , ma più puliti.

Invece di spiegarli, c'è n ottimo PHP RFC che spiega entrambi . I tratti stanno arrivando a PHP tra l'altro, sono già impegnato in tronco.

In sintesi

OOP è la chiave della modularità, secondo me, e come la conosciamo oggi OOP è ancora incompleta .

1
dukeofgaming

Rischio di ridicolizzare e confessare, ho usato solo OOP molto recentemente. Non mi viene automaticamente. La maggior parte della mia esperienza riguarda database relazionali, quindi penso in tabelle e join. Si sostiene che sia meglio impararlo dall'inizio, il che evita di dover ricollegare il tuo pensiero quando si tratta di programmazione. Non ho quel lusso e mi rifiuto di rovinare la mia carriera su una teoria della torre d'avorio. tutto il resto, lo capirò.

All'inizio pensavo che l'intero concetto non avesse senso. Sembrava inutile e troppi problemi. Lo so, questo è un discorso folle. Ovviamente ci vuole un certo livello di comprensione prima che tu possa apprezzare i benefici di qualsiasi cosa o respingerlo per metodi migliori.

Il riutilizzo del codice richiede la volontà di non ripetere il codice, una comprensione di come realizzarlo, una pianificazione anticipata. Dovresti evitare di riutilizzare il codice quando hai deciso di avere un caso in cui non ne vale la pena? E nessun linguaggio è così rigorosamente OO che genererà un errore quando pensa che dovresti aver ereditato il codice da un'altra classe. Nella migliore delle ipotesi forniscono un ambiente favorevole all'implementazione.

Penso che il più grande vantaggio di OOP è l'accettazione generale di come dovrebbe essere organizzato il codice. Tutto il resto è sugo. Un team di programmatori potrebbe non essere pienamente d'accordo su come dovrebbero essere strutturate tutte le classi, ma dovrebbero essere in grado di trovare il codice.

Ho visto abbastanza codice procedurale per sapere che potrebbe essere ovunque, e talvolta è ovunque.

1
JeffO

Leggendo i post precedenti, alcune osservazioni:

  • Molti pensano che il riutilizzo del codice in OOP implica l'ereditarietà. Non sono d'accordo. Interfacce e contratti sono il nucleo del riutilizzo del codice in OOP sistemi. OOP è un tentativo di casella grigia nella creazione di una tecnologia componente.
  • La differenza tra "quadri" specifici di dominio e generici come soggetto di riutilizzo mi sembra troppo astratta. A mio avviso, un componente (un contratto di interfaccia conciso, minimale e riutilizzabile e l'implementazione dietro) può essere fatto solo se il problema che affronta è ben compreso. Un componente specifico del dominio, che consente agli esperti non di dominio di svolgere il proprio lavoro con meno conoscenze sul dominio, è un componente (ri) utile. Gli utenti devono comprendere l'interfaccia, tanto meno le complessità del dominio problematico.
  • Livelli di riutilizzo spesso dimenticati: riutilizzo di idee, riutilizzo di specifiche, riutilizzo di architettura/design, riutilizzo di interfacce, riutilizzo di test case. Il riutilizzo del codice non è sempre favorevole. Ma è spesso un grande risparmio di tempo attenersi a un'architettura specifica per affrontare un nuovo prodotto simile.
  • I modelli OOP Design (Gamma et. Al) ai miei occhi hanno elaborato tecniche di implementazione tattica anziché essere significativi nel contesto del riutilizzo del codice su una scala più ampia. Aiutano a scrivere un'applicazione con OOP elementi, ma non li vedrei come una soluzione alla domanda "riutilizzo del codice" oltre a una singola applicazione.
  • Forse non è giusto: 20 anni di esperienza in C/C++/C # e 6 mesi di programmazione funzionale (F #). Un elemento importante per consentire il riutilizzo è: le persone devono trovare facilmente "l'interfaccia", studiarla, comprenderla, quindi usarla. La pura programmazione funzionale non mi rende facile vedere la struttura, i candidati per il riutilizzo o dove tutto inizia e dove tutto finisce. Lo "zucchero sintattico" tanto apprezzato è spesso il sale nei miei occhi, che mi impedisce di vedere facilmente cosa succede. Pertanto, avrei meno probabilità di provare a riutilizzare un funzionale (che cos'è - un gruppo di funzioni?), Che potrebbe avere effetti collaterali nascosti che non riesco nemmeno a vedere (valutazione pigra, monadi, ...). Non fraintendetemi, la programmazione funzionale ha lati molto interessanti, ma tutti i punti di forza proclamati vedo con una buona dose di dubbi. Sono molto curioso di sapere cosa porterà il futuro post-funzionale e spero di vederlo prima di ritirarmi;)
  • Specifica, progettazione, implementazione sono viste accoppiate, ma non facilmente percorribili sulla "stessa cosa". Molto più vitale per una maggiore produttività futura rispetto a un nuovo paradigma di programmazione è, per colmare il divario, per aumentare (ragionamento automatizzato, tracciabilità) i vantaggi reciproci tra tali punti di vista. Linguaggi di specifica formalizzati, notazioni di prova standardizzate (ad es. Ttcn3) e linguaggi di programmazione che supportano la verifica di interfacce e contratti rispetto a specifiche senza sporcare commenti possono essere ciò di cui abbiamo più urgentemente bisogno.
0
BitTickler

Il problema è imho più sottile:

  1. OOP è un ottimo metodo per strutturare il codice con stato mutabile. Incapsulando lo stato in oggetti, il codice stateful imperativo diventa più comprensibile perché, ad esempio, se un pezzo di stato viene espresso come campi privati ​​di una classe, sai che almeno questo particolare pezzo di lo stato può essere modificato solo con metodi di questa classe. (E puoi facilmente rompere questo vantaggio abusando dell'ereditarietà, tra l'altro.) Ora questo è abbastanza, ma waaay meglio che non avere nemmeno questo.
  2. il codice con stato modificabile è intrinsecamente difficile da riutilizzare. Molto più difficile del codice utilizzando strutture di dati immutabili.

Quindi OOP in sé non è male dal punto di vista della creazione di codice riutilizzabile, ma i tipi di codice che vengono scritti usando OOP sono intrinsecamente difficili da riutilizzare.

Inoltre, programmazione funzionale può risultare in codice più riutilizzabile . Ma ottenere le astrazioni giuste per scrivere un codice funzionale sano nel rispetto di una scadenza potrebbe non essere fattibile. E le astrazioni "a metà destra" saranno più facili da esprimere OOP. E non tenderà a rendere più facile riutilizzare il codice - un livello più elevato di astrazioni significa che la comprensione del codice richiederà un investimento iniziale più elevato a causa della limitata capacità cognitiva dei programmatori.

Come esempio pratico: Il codice di gioco comporta un sacco di stato mutevole, perché questo è il modo naturale di pensare alla codifica di un gioco, a meno che non sia un puzzle/algoritmico, quindi finisce per essere strutturato usando OO. E ovviamente è difficile riutilizzarlo. Ma lo stesso codice, contenente la stessa conoscenza, sarebbe ancora più difficile riutilizzarlo senza OOP. E riscriverlo per renderlo funzionale potrebbe essere necessario cambiare totalmente il modo in cui pensi a quel codice, la conoscenza dietro di esso. Sì, il risultato la conoscenza dietro il codice sarebbe molto più chiara dopo il OO a FP riscrivere forse ... ma il costo potrebbe essere enorme e potrebbe essere il tipo di costo che dovrebbe essere pagato anche dalle persone desiderando riutilizzare il codice incredibilmente intelligente e ben astratto che si finisce con , così paradossalmente, le persone finirebbero per non riutilizzare il codice, anche se tecnicamente è più riutilizzabile.

... che porta all'ultima sottigliezza: il riutilizzo del codice riguarda l'interfaccia People | Code, non solo il codice. OOP fa un buon lavoro nel servire questa interfaccia perché si associa bene a quante persone pensano a molti tipi di codice scritti al giorno d'oggi. FP potrebbe essere migliore per il codice riutilizzare, ma non per riutilizzare facilmente il tipo di codice che le persone devono effettivamente scrivere al giorno d'oggi. Questo cambierà come il tipo di codice di cui abbiamo bisogno scrivere le modifiche.

Post scriptum E se qualcuno vuole dire che "OO non riguarda lo stato mutabile, puoi anche avere OO con stato immutabile" ... Io chiamo che "FP usa le classi come spazi dei nomi". È fantastico quando funziona per te ed evita alcune carenze dei sistemi dei moduli di alcune lingue e può comportare un codice più riutilizzabile. Ma questo non è OO;)

0
NeuronQ

OOP Fornisce una serie di strumenti utili che ti consentono di scrivere codice che può essere utilizzato in più posizioni di quelle che potresti avere senza quegli strumenti. Se scrivi una funzione PrintIt che accetta qualsiasi oggetto vecchio e chiama .toString() su di esso, avrai riutilizzato quel codice non appena lo chiamerai con più di un tipo di oggetto. Con questi strumenti, ogni riga di codice fa di più.

La programmazione funzionale è molto calda in questo momento tra gli hipster. Ti fornisce un set di strumenti completamente separato per fare di più ogni riga di codice. Probabilmente non è meglio o funziona, ma fornisce un altro strumento nella casella degli strumenti.

(C'era un'idea folle per un ulteriore livello di riutilizzo orientato agli oggetti: l'idea era che potremmo definire una singola classe Customer e usarla in ogni applicazione che abbiamo scritto. Quindi le applicazioni sarebbero solo un po ' incollare qua e là. Questo non ha funzionato. Ma ciò non significa che il OO fallito, o anche che il riutilizzo sia fallito. I tipi base di riutilizzo del codice all'interno delle applicazioni lo hanno reso possibile per scrivere applicazioni che hanno fatto di più e per scriverle più velocemente.)

0
Sean McMillan