E perché si parla spesso?
Come se sapessi cosa sia la programmazione OO ovviamente ... ma la gente dice sempre "Oh OO riutilizzo è il più grande mito della programmazione di sempre".
Che cosa significa esattamente?
E perché si parla spesso?
Come se sapessi cosa sia la programmazione OO ovviamente ... ma la gente dice sempre "Oh OO riutilizzo è il più grande mito della programmazione di sempre".
Che cosa significa esattamente?
C'era una credenza (o almeno c'è la convinzione che esistesse una credenza) che con OO avremmo vaste librerie di oggetti riutilizzabili che renderebbero lo sviluppo di applicazioni facile come collegare scatole in un diagramma. Potresti aver notato che questo non è accaduto.
Nella convinzione errata che il codice possa essere scritto perfettamente la prima volta, ho visto diversi progetti tentare di sviluppare una libreria "riutilizzabile" e quindi creare applicazioni usando la libreria. Tutti questi progetti successivamente fallirono, o finirono per costare molto di più di un semplice approccio top-down. A causa dell'effetto Dunning-Kruger , molti sviluppatori sottovalutano la difficoltà di produrre un biblioteca utilizzabile, mentre sopravvaluta la propria capacità di farlo. Peggio ancora, gli sviluppatori che sono attratti dalla creazione di queste librerie spesso credono di essere più intelligenti e svolgono un lavoro più importante rispetto ai programmatori di applicazioni e di conseguenza incolpano le difficoltà con la libreria sugli utenti.
La maggior parte delle librerie di alta qualità sono state create in due modi:
Penso che le persone si stiano riferendo a progetti software che non hanno beneficiato del riutilizzo. Ci sono tre ragioni per cui posso pensare:
Tuttavia, questi problemi non sono esclusivi di OO.
Per ottenere vantaggi reali dal riutilizzo orientato agli oggetti, è necessario comprendere i diversi tipi di riutilizzo, nonché dove e come applicarli.
Buone letture
Riutilizzare è sia una realtà che un mito. Da quando ho iniziato a programmare, abbiamo sempre avuto un riutilizzo.
La realtà è che abbiamo un ampio riutilizzo senza il quale non saremmo in grado di fare i progetti che facciamo. Il riutilizzo inizia con le librerie principali fornite con il linguaggio e continua attraverso framework che semplificano enormemente lo sviluppo.
All'interno delle organizzazioni e dei progetti il riutilizzo può essere un mito più che una realtà. Parte di questo è colpa dei programmatori che hanno bisogno di una classe per fare X in modo che scrivano una classe per fare X. Il fatto che l'organizzazione abbia 20 classi, e il progetto ne ha già 5, non entra nella mente dei programmatori. Questo può estendersi nelle librerie in cui riusciamo davvero a riutilizzare. DRY può essere davvero utile per ridurre questa tendenza, specialmente se applicata a livello di progetto, di squadra o di organizzazione.
Molte organizzazioni non investono nel riuso. È stata la mia esperienza che questo è a loro danno. La mia prima esperienza con la progettazione per il riutilizzo mi ha permesso di fornire sistemi che a mio avviso sono stati sottovalutati in un anno utilizzando la metodologia esistente in tre mesi. Quell'esperienza era pre-OO.
Dove le organizzazioni si perdono per il riutilizzo si trova nel livello dell'oggetto business. SOA è un approccio che credo possa essere utilizzato per ottenere il riutilizzo. Tuttavia, l'implementazione di callout probabilmente scoraggia il suo utilizzo se si desidera una funzionalità integrata. La creazione di alcune librerie di servizi di base che possono essere utilizzate da più applicazioni o l'utilizzo forzato in un progetto può avere vantaggi reali.
Uno svantaggio del riutilizzo in un'azienda è che i cambiamenti possono avere un impatto su molti sistemi. Senza un buon portafoglio di applicazioni, questo può essere difficile da tracciare. Tuttavia, è la mia esperienza che i servizi che offrono maggiori benefici sono probabilmente relativamente stabili e diventano tanto più tanto più vengono utilizzati.
Prima di tutto, lasciami dire che
L'overselling consisteva nel dire alle persone (ho sentito certamente questo) che lo sviluppo di software equivaleva a combinare solo moduli preesistenti in nuovi progetti. Le analogie utilizzate erano: fabbriche, assemblaggi meccanici, Lego, ponti, cose del genere.
Come se coloro che facevano la vendita sapessero la prima cosa sulla costruzione di ponti, ecc.
Personalmente, penso che un concetto migliore sia DSL (linguaggio specifico del dominio). Ogni programma è una stringa di codice in una lingua. I nomi, i verbi e i modi in cui è possibile combinarli producono il codice più conciso e gestibile quando esprimono bene i concetti mentali nel problema da risolvere. È un approccio diverso rispetto all'assemblaggio meccanico.
A volte OOP (e sfruttando le classi preesistenti) è lo strumento giusto da utilizzare per le parti del lavoro. È lontano dall'intera storia.
Il vero significato è solitamente che la persona che dice questo ha un'agenda, solitamente legata alla promozione di un linguaggio non orientato agli oggetti, e pensano che un buon modo per raggiungere il loro obiettivo sia abbattere la concorrenza. (Ehi, funziona bene per i politici ...)
O questo, o tutta la loro esperienza con la programmazione orientata agli oggetti è stata in C ++ - che ha implementato quasi ogni dettaglio di OOP in modo errato e rende il riutilizzo molto più difficile di quello che deve essere - e non sono consapevoli che esistono sistemi migliori in cui il riutilizzo è abbastanza comune e funziona davvero bene.
Il riutilizzo OO è più o meno lo stesso del riutilizzo non OO. Le lingue più sensibili consentono la scrittura di librerie, anche di C. Solo noi generalmente usiamo il termine più sensato "uso". Usiamo una biblioteca, dicendo che il riutilizzo sembrerebbe stupido. L'uso della frase "riutilizzo OO" probabilmente indica ingenuità.
Leggi altre domande sui tag object-oriented programming-languages code-reuse