Ho spesso sentito dire che gli oggetti non sono stati pubblicati in termini di riutilizzo del codice. Sei d'accordo? Se ritieni di non averlo, perché no?
No, non necessariamente.
Gli oggetti offrono una semantica migliore, l'organizzazione del codice / funzionalità e, possibilmente, la facilità d'uso.
Le librerie ben progettate promettono il riutilizzo del codice, non gli oggetti di per sé.
Onestamente non sono sicuro che "riutilizzare il codice" sia davvero ciò che qualcuno sta cercando (o almeno dovrebbe essere dopo). La mia filosofia è "componenti software", il che significa migliore manutenibilità attraverso interfacce efficienti ed evitare accoppiamenti non necessari. "Il riutilizzo del codice" è una delle cose che ne viene fuori a volte - un codice inutilmente duplicato è un segno che hai organizzato le cose nel modo sbagliato e ovviamente è un problema da mantenere.
Per rispondere alla domanda un po 'più direttamente, c'è una raccolta di strumenti abbastanza buoni per evitare di ripetersi: eredità, tratti, delega, funzioni di ordine superiore, ecc. Di questi, le persone tendono a confondere l'ereditarietà con OO nel suo complesso - e anche loro tendono a esagerare un po ', se me lo chiedi. Forse è da lì che parte l'atmosfera di "OO sucks": trovare l'eredità bloccata dove non ha il diritto naturale di essere:)
No, "oggetti" non hanno reso il riutilizzo del codice più facile o più comune. Le stesse preoccupazioni che impediscono il riutilizzo del codice in un programma modulare (progettare, testare e documentare un'API generica richiede uno sforzo molto più oneroso rispetto alla scrittura di una routine one-off e il jack di tutte le negoziazioni potrebbe essere il master of none - la logica destinata a essere riutilizzata potrebbe non essere ottimizzata per gli usi a cui è effettivamente rivolta) si applica ai programmi OO, con l'ulteriore preoccupazione che un modello di oggetto mal progettato possa ostacolare il riutilizzo di altrimenti riutilizzabile codice.
OO è un'astrazione pratica per molti problemi, ma fai attenzione alla campagna pubblicitaria anni '80 -'90: non risolve magicamente i problemi fondamentali del nostro lavoro più di quanto non faccia per te waffle mentre dormi.
Non mi aspetto che tutti gli oggetti vengano riutilizzati, ma abbiamo un sacco di oggetti che riutilizziamo in molti progetti diversi. Abbiamo anche oggetti che vengono riutilizzati su un solo progetto. Spesso utilizziamo gli stessi oggetti di business (o oggetti di trasferimento dati) e oggetti di business logic da un'app desktop Click-Once, un'app Web e un'app per telefono tutti per lo stesso progetto.
Dove hai sentito che OO non fornisce il riutilizzo? E quale era il ragionamento? Forse il design dei loro oggetti li ha costretti in quella situazione ...
Alcuni programmatori copieranno e incolleranno in qualsiasi lingua e stile.
I programmatori davvero bravi possono evitare la maggior parte delle operazioni di copia e incolla in quasi tutte le lingue.
Trovo che i pattern OO tendano a incoraggiare il riutilizzo. Ho visto il codice Java che è stato scritto in uno stile non OO (in cui i dati sono stati separati dal codice a causa di un orribile ORM) e il riutilizzo era veramente miserabile - ma in OO gli stessi programmatori hanno fatto un lavoro migliore in progettazione ( e riutilizzare).
Anche nei casi in cui utilizziamo pattern non-oo o anti-patters come setter / getter, istruzioni switch, classi interne anonime, funzioni enormi e simili, ho visto il riutilizzo del codice andare giù e il boilerplate salirà .. .significantly.
ps. So che le persone avranno problemi con il paragrafo precedente, quindi spiegherò un po '.
I setter e i getter causano problemi di OO perché ti permettono di operare sui membri di un oggetto (un oggetto dovrebbe manipolarli è membri OWN) Questo distribuisce il codice che opera sulla tua classe in altre classi che richiedono di copiare la funzionalità intorno al setter / getter. Questo vale anche per le Proprietà - solo perché le Proprietà sono più facili non le rende "Buone" in tutte le situazioni.
Il codice nelle classi interne anonime non può essere riutilizzato e la gente dimentica che molte cose (come gli ascoltatori) possono e dovrebbero essere classi a pieno titolo - questo vale anche per le chiusure! Se hai utilizzato una classe interna anonima per implementare qualcosa come un listener, è molto più probabile che copi e incolli la tua implementazione piuttosto che estrarre il codice in un metodo o nella sua classe e chiamarlo invece. Le chiusure possono anche migliorare la riusabilità - dipende solo da come le usi.
In molti casi le funzionalità disponibili ti consentono di definire la struttura del codice. OO è ancora più potente quando si tratta di aiutarti a visualizzare tutto il codice e come interagisce, ma questa è un'altra domanda.
Gli oggetti non hanno più capacità di fornire il riutilizzo del codice rispetto a un montascale o ad altre attrezzature per il fitness in grado di fornire la perdita di peso. Gli sviluppatori devono essere motivati a utilizzare gli strumenti correttamente.
Quando i team software assegnano un valore superiore al riutilizzo del codice testato rispetto a quello che fanno per mantenere tutti i dettagli nella loro testa, vedrai molto più oggetti e metodi a grana fine e quindi più riutilizzo del codice.
OOP ti offre più modi per riutilizzare il codice
non c'è un proiettile d'argento
su cosa ci hai messo e cosa ti aspettavi in cambio!
Sì. Una buona programmazione orientata agli oggetti promuove la separazione delle preoccupazioni, l'accoppiamento basso, l'alta coesione e l'occultamento delle informazioni. Queste cose sono tutte fondamentali per il codice riutilizzabile.
Direi che il principale vantaggio di OOP è la modularità e la modificabilità, piuttosto che il riutilizzo, ma questa è un'altra domanda.
Gli oggetti abilitano la ricerca del codice ma in quanto tale non è la tecnica più adatta. Penso che il riutilizzo del codice sia promosso attraverso tecniche relative agli oggetti come ereditarietà, polimorfismo, sovraccarico e modelli.
Sì, lo fanno, la possibilità di estendere (ereditare) da una cleary di super classe contribuisce al riutilizzo del codice, non sono sicuro di come qualcuno possa obiettare diversamente. Puoi semplicemente estendere una classe e sovrascrivere un metodo, mentre usi il resto dalla super classe, se questo non aiuta a riutilizzare il codice, allora non so cosa sia
Se è stato consegnato alla loro promessa di riutilizzo del codice finora? Sì, se i programmi scritti con OOP in mente applicano i modelli di progettazione con saggezza. Altrimenti, per lo più no. Ma guardando la popolarità di programmi non banali su larga scala che i sistemi Adobe, Google e simili scrivono con C ++ o Java o altri linguaggi OOP, direi che l'OOP ha una lunga strada da percorrere prima che si dissolva. Quel tempo sarà molto più adatto a porre questa domanda e potrebbe aiutare a fornire un lavoro di base per un nuovo paradigma.
Leggi altre domande sui tag object-oriented code-reuse