Ha OOP mantenere la promessa di riutilizzo del codice? Quali alternative ci sono per raggiungere il riutilizzo del codice?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/7618

Domanda

Forse la più grande promessa di utilizzare paradigma object-oriented è il riutilizzo del codice. Alcuni controversia che questo è stato raggiunto. Perché (non) è stato raggiunto?

codice fa il riutilizzo come OOP lo definisce, progetti di rendere più produttivo?

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

Probabilmente siamo tutti d'accordo che il riutilizzo del codice è 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? sono lì migliori metodi di riutilizzare il codice ottenuto di orientamento agli oggetti, sub-classificare, il polimorfismo, ecc? Quali modi sono migliori? Perché

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

È stato utile?

Soluzione

Il riutilizzo del codice è una buona idea. non un grande .

ho una prospettiva tratto da circa 30 anni di ingegneria del software, cercando di "riuso".

ho iniziato indagare "il riutilizzo del codice" come un tema di ricerca negli anni '80, dopo aver scoperto che avevo riutilizzato il design di un sistema operativo che ho costruito nei primi anni '70, per un altro sistema operativo ho costruito alla fine degli anni '70.

La buona parte di riutilizzo del codice è la possibilità di riutilizzo a volte onesti a dio il codice preesistente. Ma il mondo è completa di codice; come si può trovare quello che vuoi? Ecco quello che io chiamo il Riutilizzo Curse :

Sono Babbo Natale (ok Open Source), e ho un sacco di 1 miliardo di componenti software. Si può avere uno qualsiasi di essi.

Buona fortuna scelta.

Per risolvere bene il problema di riutilizzo:

  • le esigenze Reuser in qualche modo di specificare che cosa ha bisogno (functionaly, le prestazioni, la lingua di destinazione, le ipotesi di ambiente, ...)
  • ci deve essere una libreria di codice "riutilizzabile" che è stato indicizzato in vari modi da questi potenziali criteri
  • qualche meccanismo deve esistere per scegliere gli elementi candidati (a un miliardo di elementi, non si può guardare a tutti loro personalmente)
  • ci deve essere un modo per Characterizer quanto lontano dalla specifica i candidati scelti sono
  • un processo regolare dovrebbe esistere per permettere al Reuser di modificare il codice riutilizzabile prescelto (Qui è il più grande contributo di OOP:. È possibile modificare un componente / oggetto esistente sovrascrivendo i suoi slot OOP non fornisce alcun altro aiuto).
  • Tutto questo deve chiaramente essere più conveniente che semplicemente ricodifica che

Per lo più ciò che è stato scoperto nel corso degli anni è che per il codice per essere riutilizzabile, è sorta di deve essere progettato a tale scopo, o contiene troppi assunti impliciti. Le maggior parte delle librerie di codice riutilizzo di successo sono stati effettivamente piuttosto piccola. Probabilmente librerie e framework sono codice "riutilizzabili" e sono di grande successo; Java e C # non riescono perché sono abbastanza buoni linguaggi di programmazione, ma piuttosto perché hanno enormi librerie ben progettato, realizzato e documentato a disposizione. Ma le persone non guardano il codice sorgente nelle biblioteche; chiamano semplicemente un'API ben documentata (progettato per essere generalmente utilizzabili).

Quello che il riutilizzo del codice non ha fatto (OOP nessuno) è fornire gli ordini di miglioramento grandezza nella nostra capacità di sistemi di codici.

Credo che il difetto principale è che qualsiasi tipo di riutilizzo del codice è fondamentalmente limitato perché il codice ha troppe ipotesi costruite nel . Se si effettua il codice molto piccolo, a ridurre al minimo le ipotesi, ma poi il costo per costruire da zero non è molto grande e gli utili di riutilizzo non sono efficaci. Se si fanno i pezzi di codice enorme, sono praticamente inutile in un nuovo contesto. Come Gulliver, sono legati alla spiaggia da un milione di piccole stringhe, e semplicemente non può permettersi di tagliare tutti.

Quello che dovremmo lavorare su riutilizzo delle conoscenze per costrutto di codice . Se siamo in grado di fare questo, allora possiamo applicare tale conoscenza al costrutto di codice di cui abbiamo bisogno, la manipolazione l'attuale serie di ipotesi.

Per fare questo, ha bisogno ancora la stessa capacità specifica di componenti software caratterizzano (ancora dovete dire quello che volete!). Ma poi si applica questa conoscenza "costruzione" per le specifiche per generare il codice che si desidera.

Come comunità, non siamo ancora molto bravo in questo. Ma le persone fanno tutto il tempo; perché non possiamo automatizzare? C'è un sacco di ricerca, e questo dimostra che si può fare in molte circostanze.

Un pezzo fondamentale di macchinari necessari per questo sono strumenti meccanici per l'accettazione "descrizioni dei componenti" (questi sono solo i documenti formali e possono essere analizzati come linguaggi di programmazione) e applicare trasformazioni del programma a loro.

I compilatori già fare questo: -} AND sono veramente bravo a classe di problemi che affrontano.

modelli UML con la generazione di codice sono un tentativo di fare questo. Non è un buon tentativo; più o meno ciò che si dice nella maggior parte dei modelli UML è "Ho dati che assomiglia a questo". Piuttosto difficile da generare un vero e proprio programma se la funzionalità è lasciato fuori.

Sto cercando di costruire , uno strumento chiamato DMS . Stato abbastanza bene distratto applicando trasformazioni del programma non tanto alle specifiche astratte per generare il codice, ma piuttosto di codice legacy per ripulirlo. (Questi sono lo stesso problema in astratto!). (Per costruire questi strumenti richiede un sacco di tempo, ho fatto questo per 15 anni e nel frattempo devi mangiare).

Ma DMS ha le due proprietà fondamentali che ho descritto sopra: la capacità di elaborare specifiche formali arbitrari, e la capacità di catturare "la conoscenza di generazione di codice", come si trasforma, e applicarle su richiesta. E notevolmente, noi generiamo in alcuni casi particolari, un certo codice piuttosto interessante rispetto alle specifiche; DMS è in gran parte costruito utilizzando sé per generare la sua attuazione. Che ha raggiunto per noi almeno una parte della promessa di (conoscenza) riutilizzo: estremamente significativi guadagni di produttività. Ho una squadra di circa 7 persone tecnici; Abbiamo scritto probabilmente 1-2 MSLOC di "specifiche" per DMS, ma avere qualche 10MSLOC di codice generato.

Sommario:. il riutilizzo delle conoscenze generazione è la vittoria, non è riutilizzo del codice

Altri suggerimenti

Codice riutilizzo si ottiene in OOP, ma si realizza anche nella programmazione funzionale. Ogni volta che si prende un blocco di codice e renderlo richiamabile dal resto del codice in modo tale che è possibile utilizzare questa funzionalità è altrove riutilizzo del codice.

Questo tipo di riutilizzo del codice rende anche il codice più gestibile perché cambiare questo blocco richiamabile cambia tutti i luoghi che si chiama. Direi che questo risultato ha aumentato la qualità e la leggibilità troppo.

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 astrarre i dettagli della struttura di dati.

Da Wikpedia:

Programmazione orientata agli oggetti ha radici che possono essere ricondotti al 1960. Come hardware e software è diventato sempre più complesso, gestibilità divenne spesso un problema. I ricercatori hanno studiato modi per mantenere la qualità del software e programmazione orientata agli oggetti sviluppato in parte a problemi comuni indirizzo enfatizzando fortemente discrete unità riutilizzabili di logica di programmazione [citazione necessaria]. La tecnologia si concentra sui dati anziché processi, con programmi composti da moduli autosufficienti ( "classi"), ciascuno dei quali (esempio "oggetti") contiene tutte le informazioni necessarie per manipolare la propria struttura di dati ( "membri"). Ciò è in contrasto con la programmazione modulare esistente che era stato dominante per molti anni, incentrata sulla funzione di un modulo, piuttosto che specificamente ai dati, ma ugualmente previsto il riutilizzo del codice, e unità riutilizzabili autosufficienti logica di programmazione, consentendo la collaborazione attraverso l'utilizzo di moduli collegati (subroutine). Questo approccio più convenzionale, che ancora permane, tende a considerare i dati e il comportamento separatamente.

Sì e No

Il riutilizzo del codice è un catch-all termine per molte attività diverse.

  1. Il riutilizzo del codice all'interno di un unico progetto. OO è perfettamente adatto per questo, un'applicazione ben progettata sarà mappato le relazioni del mondo modellato da vicino, eliminando così il codice duplicato il più possibile e consigliabile . Tuttavia, si può sostenere che le tecnologie pre-OO potrebbe ottenere la stessa cosa, che è vero, ma OO è per molti versi più comodo.
  2. librerie terze parti Questo sembra funzionare altrettanto bene con o senza OO.
  3. codice cross-scopo riutilizzo Il più grande promessa di code-riutilizzo di OO è che il codice, una volta scritto per un'applicazione può essere successivamente riutilizzato per un altro, che non era stato specificamente progettato per. Questa è stata tutta la rabbia, quando la nozione di OO filtrato attraverso le porte degli uffici di gestione più elevati, e OO completamente non è riuscito a raggiungerlo. Si è scoperto che scopo era un aspetto cruciale della progettazione OO (e forse tutto il codice di procedura, ma questa è solo la mia teoria) e tentativi di riproporre il codice è conclusa nei disastri di manutenzione. (Il ben noto antipatternsof un vecchio quadro nessuno osa di modificare e il suo amico, i po-diversi-quadri-per-ogni-app in genere derivano da qui.)

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

http://www.udidahan.com/2009/06/07/ the-fallacia-di-riutilizzo /

Ecco l'inizio del post:

Questa industria è pre-occupato con riutilizzo.

C'è questa convinzione che, se abbiamo appena riutilizzato più codice, tutto sarebbe meglio.

Alcuni addirittura andare così fino a dire che la intero punto dell'oggetto orientamento era riutilizzo - non lo era, era incapsulamento la grande cosa. Dopo di che componente orientamento era la cosa che avrebbe dovuto fare il riutilizzo accadere. A quanto pare, che non ha pan così bene o perché qui siamo ora pinning le nostre speranze su reuseful servizio di orientamento.

interi libri di modelli sono stati scritto su come raggiungere il riutilizzo con l'orientamento del giorno. Servizi sono stati classificati in tutte le direzioni nel tentativo di raggiungere questo obiettivo, da un'entità servizi e servizi di attività, attraverso servizi di processo e servizi di orchestrazione. Composizione servizi è stato presentato come la chiave per il riutilizzo, e la creazione di riutilizzabile servizi.

I potrebbe anche lasciare a voi nel sporco segreto-po:

Il riutilizzo è un errore

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

Molti programmi non ha strutture di codice che è ricorrente. Per questo alcuni modelli di progettazione sono utilizzati nel OOP-mondo, ma questo può essere raggiunto da funzioni ricorsive e pattern matching in linguaggi di programmazione funzionale. Per ulteriori informazioni su questo vedere il primo capitolo di mondo reale programmazione funzionale .

Credo che nel profondo eredità in OOP può essere fuorviante, in molti casi. Hai una classe e molti dei metodi strettamente correlati sono implementati in file diversi. Come Joe Armstrong dire di OOP:

Il problema con linguaggi orientati agli oggetti è loro hanno tutto questo ambiente implicita che portano in giro con loro. Volevi una banana, ma quello che si ottenne fu un gorilla che tiene la banana e l'intera giungla.

funzioni ordine elevato sono anche molto utile quando si tratta di riutilizzo del codice esempio map e foldr che è il fondamento per Google MapReduce .

Messaggio asincrono passando è anche un buon modo per organizzare software complesso, e qualche stato del computer gli scienziati che gli oggetti è stato assunto per comunicare con la vicenda asincrono come nel Tell, non chiedere principio OOP. Vedere di più su questo in Object Oriented Programming:? La strada sbagliata sono stati Joe Armstrong è citato:

ho iniziato a chiedersi su cosa programmazione orientata agli oggetti è stato e ho pensato Erlang non è stato orientato agli oggetti, si trattava di un linguaggio di programmazione funzionale. Poi, il mio relatore di tesi, ha detto "Ma ti sbagli, Erlang è estremamente orientato agli oggetti". Ha detto linguaggi orientati agli oggetti non sono orientati agli oggetti. Potrei pensare, anche se non sono del tutto sicuro se credo che questo o no, ma Erlang potrebbe essere l'unico orientato agli oggetti linguaggio perché i 3 principi della programmazione orientata agli oggetti sono che si basa su di messaggi , che si dispone di isolamento tra gli oggetti e hanno polimorfismo .

messaggio asincrono passando come nei sistemi event-driven in Erlang è anche un ottimo modo per sistemi DECOUPLE e accoppiamento lasco è importante nei sistemi complessi. Con un sistema sufficientemente disaccoppiato si può evolvere il sistema mentre è in esecuzione, forse su nodi differenti. Unibet ha fatto una grande presentazione su questo: dominio Event Driven Architecture

Comunque penso che la maggior parte del riutilizzo del codice viene fatto utilizzando librerie e framework.

Il tubo unix umile ha fatto di più per il riutilizzo del codice di qualsiasi altra cosa che è venuto e andato. Gli oggetti appena capitato di essere un modo intuitivo di strutturazione del codice, quando è arrivato e la gente più tardi iniziato a virare su qualsiasi cosa su di esso. 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 di ereditarietà di classe è un povero sostituto per quello che un meccanismo di riutilizzo del codice in realtà dovrebbe essere.

OOP non è speciale; è possibile rendere il codice riutilizzabile con o senza OOP. funzioni pure sono particolarmente riutilizzabili : per esempio, java.lang.math.sqrt(double) prende un numero in e dà un numero fuori. No OOP, ma sicuramente più riutilizzabili che la maggior parte del codice là fuori.

Da un funzionale vista programmazione orientata agli oggetti è principalmente sulla gestione di stato.

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

Vuoi avere centinaia di metodi in un elenco di classe? Metodi pubblici sono considerati un'interfaccia allo stato interno che si desidera conservare piccolo.

Purtroppo, invece di (ri) utilizzando un sacco di piccole funzioni, alcune persone funzionalità duplicato. Per me questo è perché OOP non incoraggiare il riutilizzo del codice il più programmazione funzionale fa.

Per quanto mi riguarda, sì, ma non tutto il tempo, e potrebbe essere stato fatto altri modi.

La maggior parte del tempo con la creazione di una classe base astratta e la creazione di implementazioni concrete di questa categoria.

Anche molti quadri fanno uso di ereditarietà per fornire il riutilizzo del codice (Delphi, Java, .Net sono solo alcuni che la primavera subito in mente).

Questo non vuol dire che un sacco di librerie di utilità e frammenti di codice non avrebbe potuto fare il lavoro come bene, ma c'è qualcosa di piacevole circa una gerarchia di oggetti ben progettato.

Nella mia esperienza, ho avuto più successo leva codice "riutilizzabile" attraverso strutture di programmazione generici (come C ++ template) che ho avuto con i principi OOP come gerarchie di ereditarietà.

OOP è troppo aperta per il riutilizzo efficace.

Ci sono troppi modi per riutilizzare. Ogni classe pubblica chiede: "! Fare una nuova istanza di me" , ogni metodo pubblico dice: "Call me!" , ogni metodo rendimenti protette: "override me " - e tutti questi modi di riutilizzo sono diverso , hanno diversi parametri, che appare in un contesto diverso, tutti hanno le loro regole diverse, come chiamare / estendo / ignorarlo.

API è meglio, è un sottoinsieme rigoroso di programmazione orientata agli oggetti (o non-oop) punti, ma nella vita reale, le API sono overfeatured e per sempre crescente, ci stiamo ancora troppi punti di connessione . Inoltre, una buona API può rendere la vita più facile, è il modo migliore per fornire l'interfaccia per la programmazione orientata agli oggetti.

Datadlow paradigma fornisce un'interfaccia rigida per i componenti, hanno porti di questi modelli:

  • consumatori (ingressi), e
  • produttori (uscite).

Dipende dal dominio, Ci sono alcuni tipi di pacchetti, per cui i consumatori ei produttori possono essere collegati si hanno stessi (o compatibili) porte. La bella parte la maggior parte di esso, che può fatto visivamente, perché ci sei parametri o tweaks orher sui collegamenti, che in realtà solo si collega un consumatore e un produttore.

I era un po 'poco chiaro, si può dare uno sguardo su "flusso di dati" tag su StackOverflow , o Wikipedia "datafow programmazione" o Wikipedia "di programmazione basato sul flusso" .

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

In Common Lisp ci sono un sacco di mezzi per raggiungere il riutilizzo:

  • tipizzazione dinamica, avendo il codice sia generico di default

  • astrazioni imperativo, vale a dire le subroutine

  • oggetto-orientamento, con ereditarietà multipla e spedizione multipla

  • sintassi astrazione, la possibilità di definire nuovi costrutti sintattici o abbreviare codice boilerplate

  • astrazioni funzionali, chiusure e di ordine superiore funzioni

Se si tenta di confrontare l'esperienza Common Lisp ad altre lingue vedrete che la caratteristica principale che facilita il riutilizzo del codice è la presenza di sia object-oriented e funzionali astrazioni. Sono più complementari che alternative: senza uno di loro si è costretti a reimplementare le caratteristiche mancanti in modo goffo. Si veda, ad esempio, le classi funtore utilizzate come chiusure e pattern matching per ottenere il metodo non estensibile spedizione.

Non c'è davvero una cosa come "riutilizzo" il modo in cui le persone lo descrivono. Il riutilizzo è un accidentale di proprietà di nulla. E 'difficile pianificare per esso. Ciò che la maggior parte delle persone intendono quando parlano di "riutilizzo" è "l'uso". E 'un termine molto meno attraente ed emozionante. Quando si utilizza una libreria, che si sta utilizzando per quello che era destinato, normalmente. Sei non il riutilizzo a meno che non si sta facendo qualcosa di veramente pazzesco con esso.

In questo senso, il riutilizzo nel mondo reale è di cose ri-proposizione. Posso riutilizzare questi posti qui e riordinarli in forma ... un letto! Non un letto molto confortevole, ma posso farlo. Questo non è il loro uso primario. Sto riutilizzarli di fuori del loro dominio originale di applicabilità. [...] Domani, io volerà ritorno in Gran Bretagna. Io non riutilizzare il piano. Mi limito a utilizzarlo per lo scopo per cui era destinato, non c'è niente di speciale o eccitante di questo.

- Kevlin Henney

ho intenzione di ridicolizzare il rischio e confesso, io ho solo usato OOP a poco tempo fa. Non viene a me automaticamente. La maggior parte della mia esperienza coinvolge i database relazionali, quindi penso che in tabelle e si unisce. C'è chi sostiene che è meglio imparare fin dall'inizio che evita di dover ricablare il tuo pensiero quando si tratta di programmazione. Io non ho questo lusso e rifiuto di rottami la mia carriera su qualche teoria torre d'avorio. Come tutto il resto, io lo scoprirò.

In un primo momento ho pensato che l'intero concetto non aveva senso. Ci sembrava problemi inutili e troppo. Lo so, questo è parlare pazzo. Ovviamente ci vuole un certo livello di comprensione prima di poter apprezzare i benefici di qualcosa o respingerlo per i metodi migliori.

Il riutilizzo del codice prende la volontà di codice non ripetere, una comprensione di come realizzarlo, pianificazione iniziale. Se si evita di riutilizzare il codice quando hai deciso di avere un caso in cui semplicemente non ne vale la pena? E nessun linguaggio è così strettamente OO che genera un errore quando pensa si dovrebbe avere ereditato il codice da un'altra classe. Nel migliore dei casi forniscono un favorevole ambiente per la sua attuazione.

Credo che il più grande vantaggio della programmazione orientata agli oggetti è l'accettazione generale di come il codice dovrebbe essere organizzato. Tutto il resto è sugo. Un team di programmatori possono non concordare pienamente su come tutte le classi dovrebbero essere strutturati, ma dovrebbero essere in grado di trovare il codice.

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

OOP ti dà più modi per il riutilizzo del codice. Questo è tutto.

orizzontale riutilizzo: aspetti, i tratti, innesti

OO Classic volte cade a corto di riutilizzo del codice, specialmente quando si va tutti eredità pazzi per la mancanza di un modo migliore per condividere effettiva funzionalità tra le classi. Per questo problema, sono stati creati meccanismi riutilizzo orizzontali, come AOP, tratti e innesti.

Aspect Oriented Programming

ritengo AOP come mancante mezza arancia di OOP. AOP non è poi così noto, ma si è fatto per il codice di produzione.

Ci proverò a spiegare in termini semplici: immaginate che si può iniettare e la funzionalità di filtro con una struttura speciale chiamata un aspetto, questi aspetti hanno "metodi" che definiscono cosa e come sta per essere colpiti attraverso riflessione , ma al momento della compilazione, questo processo è chiamato tessitura .

Un esempio potrebbe essere un aspetto che ti dice "per tutti i metodi di alcune classi che iniziano con get, si programma scriverà un file di registro i dati che è stato ottenuto e il tempo era ottenere".

Guarda questo due colloqui, se si vuole capire meglio AOP:

Tratti & Innesti

Tratti sono un altro costrutto per la definizione del codice riutilizzabile che OOP complemento, sono simile a mixins , ma più pulito.

Piuttosto che spiegare, non c'è una grande PHP RFC che spiega sia . Tratti vengono a PHP btw, sono già rimette ad tronco.

In sintesi

OOP è fondamentale per la modularità, ancora, a mio parere e come noi comunemente conosciamo oggi OOP è ancora incompleto .

OOP Fornisce una serie di strumenti utili che consentono di scrivere codice che può essere utilizzato in più luoghi che si potrebbe avere, senza questi strumenti. Se si scrive una funzione PrintIt che prende qualsiasi vecchio oggetto e chiama .toString() su di esso, si avrà riutilizzato che il codice non appena lo si chiama con più di un tipo di oggetto. Con questi strumenti, ogni linea di codice fa di più.

La programmazione funzionale è molto caldo in questo momento tra i hipsters. Esso fornisce un tutta separato un set di strumenti per rendere ogni riga di codice fare di più. Probabilmente non è migliore o opere, ma offre un altro strumento nella casella degli strumenti.

(C'era una pazza idea per un intero livello supplementare di orientata agli oggetti riutilizzo:. L'idea era che potremmo definire una singola classe Customer e utilizzarlo in tutte le applicazioni che abbiamo scritto applicazioni Poi sarebbe solo un po 'di colla qui e là. Questo non ha funzionato. Ma questo non significa che il OO non riuscita, o anche che il riutilizzo non è riuscito. I principali tipi di riutilizzo del codice all'interno di applicazioni hanno permesso di scrivere le applicazioni che hanno fatto di più, e scriverle più veloce.)

La lettura dei messaggi di cui sopra, alcune osservazioni:

  • Molti pensano che il riutilizzo del codice in OOP implica eredità. Non sono d'accordo. Interfacce e contratti sono il nucleo per il riutilizzo del codice nei sistemi OOP. OOP è un tentativo di scatola grigia nella creazione di una tecnologia dei componenti.
  • La differenza tra specifiche di dominio e "quadri" generici come oggetto di riutilizzo ritenuto me troppo astratta. A mio parere sulle cose, un componente (una concisa, contratto di interfaccia minimale e riutilizzabile e il dietro implementazione) può essere fatto solo se il problema si rivolge è ben compreso. Un componente dominio specifico, che consente agli esperti non dominio per fare il loro lavoro con meno conoscenza del dominio è una (ri) componente utile. Gli utenti devono capire l'interfaccia, meno la complessità del dominio del problema.
  • I livelli di riutilizzo spesso dimenticato: Idea riutilizzo, specifica il riutilizzo, Architettura / Design riutilizzo, Interfaccia riutilizzo, Test-caso riutilizzo. Codice riutilizzo non è sempre favorevole. Ma è un grande risparmio di tempo, spesso di attenersi a una specifica architettura per affrontare un nuovo prodotto simile.
  • I modelli di programmazione orientata agli oggetti di design (Gamma et. Al) nei miei occhi elaborato tecniche di implementazione tattiche piuttosto che essere significativo nel contesto di riutilizzo del codice su una scala più ampia. Essi aiutare a scrivere un programma con elementi OOP, ma non vorrei vederli come una soluzione alla domanda "riutilizzo del codice" al di là di una singola applicazione.
  • Forse non è giusto: 20 anni di C / C ++ / C # esperienza e 6 mesi di programmazione funzionale (F #). Un elemento importante di consentire il riutilizzo è: La gente ha bisogno di trovare facilmente "l'interfaccia", studiarla, capirla, quindi utilizzarlo. programmazione funzionale puro non rendono facile per me vedere la struttura, i candidati per il riutilizzo o dove tutto inizia e dove tutto finisce. La tanto decantata "zucchero sintattico" spesso è il sale nei miei occhi, mi impedisce di facilmente vedere cosa succede. Questa convenzione avrei meno probabilità cercare di ri-utilizzare un funzionale (cos'è - mazzo di funzioni?), Che può avere nascosti effetti collaterali non riesco nemmeno a vedere (valutazione pigra, monadi, ...). Non fraintendetemi, la programmazione funzionale è molto raffreddare le parti, ma tutti i punti di forza proclamato che vedo con una buona dose di dubbio. Sono molto curioso di ciò che il futuro post-funzionale porta e la speranza di vederlo prima di ritirarmi;)
  • Specification, progettazione, implementazione sono accoppiati, ma non facilmente attraversabili vista sulla "stessa cosa". Molto più vitale per una maggiore produttività futura di un nuovo paradigma di programmazione è, per chiudere il gap, per aumentare (automatizzato ragionamento, tracciabilità) i benefici reciproci tra quelle viste. Formalizzati linguaggi di specifica, notazioni di test standardizzati (ad esempio ttcn3) e linguaggi di programmazione che supportano la verifica delle interfacce e dei contratti nei confronti di specifiche senza commento-littering potrebbe essere quello che ci serve più urgentemente.

Il problema è più sottile imho:

  1. OOP è un ottimo metodo per strutturare il codice con stato mutevole . Incapsulando lo stato in oggetti, codice statefull imperativo diventa più comprensibile perché, per esempio, se un pezzo di Stato è espressa come campi privati ??di una classe, si sa che almeno questo particolare pezzo di stato può essere modificato solo dal metodi di questa classe. (e si può facilmente rompere questo beneficio abusando eredità, btw). questo è ora sufficiente, ma mooolto meglio che non avere anche questo.
  2. codice con stato mutevole è intrinsecamente difficile riutilizzo . Modo più difficile di codice utilizzando strutture di dati immutabili.

OOP in sé non è male da POV di rendere il codice riutilizzabile , ma il tipo di codice che vengono scritti usando OOP sono intrinsecamente difficili da riutilizzare .

Inoltre, programmazione funzionale può risultati in codice più riutilizzabile . Ma ottenere le astrazioni diritto di sano scrittura codice funzionale nel rispetto di un termine non può essere fattibile. E "half-destra" astrazioni sarà più facile esprimere stile OOP. E non tenderà a portare a più facile il riutilizzo del codice -. Più elevato livello di astrazioni significa che il codice comprensione richiederà un investimento iniziale più elevato da programmatori capacità cognitive limitate

Come esempio pratico: il codice di gioco comporta un sacco di stato mutevole, perché questo è il modo naturale di pensare di codifica di un gioco, a meno che non si tratta di un molto puzzle / uno algoritmico, così finisce ovviamente up di essere strutturato usando OO. E, naturalmente, è difficile da riutilizzare. Ma lo stesso codice, che contiene le stesse conoscenze, sarebbe ancora più difficile il riutilizzo senza OOP . E riscrittura che sia funzionale necessità stile potrebbe cambiando totalmente il modo in cui si pensa che il codice, la conoscenza dietro di esso. Sì, il risultante conoscenze dietro il codice sarebbe molto più chiara dopo il OO di FP riscrivere forse ... ma il costo potrebbe essere enorme e potrebbe essere il tipo di costo che avrebbe anche essere pagato da parte di persone che desiderano riutilizzare il incredibilmente intelligente e bene il codice astratto si finisce con , così paradossalmente, la gente finirebbe per non riutilizzare il codice, anche se tecnicamente è più riutilizzabile.

... che porta fino all'ultimo sottigliezza: il riutilizzo del codice è di circa Persone | Codice l'interfaccia, non per il solo codice. OOP fa un lavoro decente di servire questa interfaccia perché le mappe bene con quante persone pensano molti tipi di codice scritto al giorno d'oggi. FP potrebbe essere migliore per il riutilizzo del codice, ma non IMHO per facilmente riutilizzare il tipo di codice che le persone effettivamente bisogno di scrivere al giorno d'oggi. Questo cambierà come il tipo di codice che abbiamo bisogno di cambiamenti di scrittura.

P.S. E se qualcuno vuole dire che "OO non si tratta di stato mutevole, si può anche avere OO con lo stato immutabile" ... io lo chiamo "FP utilizzando le classi come spazi dei nomi". E 'bello quando funziona per voi ed evita alcune carenze dei sistemi di moduli di un certo linguaggio e può risultare in codice più riutilizzabile. Ma questo non è OO;)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top