Ho sentito spesso dire che gli oggetti non sono stati consegnati in termini di riutilizzo del codice. Sei d'accordo? Se ritieni di non averlo fatto, perché no?

No, non necessariamente.

Gli oggetti offrono una migliore semantica, organizzazione del codice / funzionalità e, possibilmente, facilità d'uso.

Le librerie ben progettate promettono il riutilizzo del codice, non gli oggetti in sé.

Sinceramente non sono sicuro che il "riutilizzo del codice" sia realmente ciò che qualcuno sta cercando (o almeno dovrebbe essere dopo). La mia filosofia è "componenti software", che significa migliore manutenibilità attraverso buone interfacce ed evitando inutili accoppiamenti. Il "riutilizzo del codice" è una delle cose che a volte sfugge a questo: il codice inutilmente duplicato è un segno del fatto che hai organizzato le cose nel modo sbagliato e, naturalmente, è un dolore 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'eredità con OO nel suo insieme - e tendono anche a usarlo un po ', se me lo chiedi. Forse è da lì che parte l'atmosfera "OO succhia": trovare l'eredità bloccata dove non ha il diritto naturale di essere :)

No, gli "oggetti" non hanno reso il riutilizzo del codice più semplice o più comune. Le stesse preoccupazioni che impediscono il riutilizzo del codice in un programma modulare (la progettazione, il test e la documentazione di un'API per scopi generici richiede uno sforzo notevolmente maggiore rispetto alla scrittura di una routine una tantum, e il vantaggio di tutte le operazioni può essere il master of none - la logica destinata a essere riutilizzata potrebbe non essere ben ottimizzata per gli usi per i quali è effettivamente utilizzata) si applica ai programmi OO, con l'ulteriore preoccupazione che un modello a oggetti mal progettato può ostacolare il riutilizzo di riutilizzabili altrimenti codice.

OO è una pratica astrazione per molti problemi, ma fai attenzione alla campagna pubblicitaria degli anni '80 -'90: non risolve magicamente i problemi fondamentali del nostro commercio più di quanto ti crei cialde mentre dormi.

Non mi aspetto che TUTTI gli oggetti vengano riutilizzati, ma abbiamo molti oggetti che riutilizziamo in molti progetti diversi. Abbiamo anche oggetti che vengono riutilizzati in un solo progetto. Consumeremo spesso gli stessi oggetti business (o oggetti di trasferimento dati) e oggetti di business logic da un'app desktop Click-Once, un'app Web e un'app telefonica tutte per lo stesso progetto.

Dove hai sentito che OO non consegna al riutilizzo? E qual era il ragionamento? Forse il design dei loro oggetti li ha costretti a 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 modelli OO tendano a incoraggiare il riutilizzo. Ho visto codice Java scritto in uno stile non OO (in cui i dati sono stati separati dal codice a causa di ORM scadente) e il riutilizzo è stato davvero miserabile - ma in OO gli stessi programmatori hanno fatto un lavoro migliore in fase di progettazione ( e riutilizzare).

Anche nei casi in cui utilizziamo modelli non oo o anti-patter come setter / getter, istruzioni switch, classi interne anonime, funzioni enormi e simili, ho visto il riutilizzo del codice andare giù e il boilerplate salire ... in modo significativo.

ps. So che le persone avranno problemi con il paragrafo precedente, quindi spiegherò un po '.

I setter e i getter causano problemi OO perché ti permettono di operare sui membri di un oggetto (un oggetto dovrebbe manipolarne i membri PROPRI) Questo distribuisce il codice che opera sulla tua classe in altre classi che richiedono di copiare la funzionalità attorno 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 affatto e la gente dimentica che molte cose (come gli ascoltatori) possono e dovrebbero essere classi a tutti gli effetti - questo vale anche per le chiusure! Se hai usato una classe interna anonima per implementare qualcosa come un ascoltatore, hai molte più probabilità di copiare e incollare l'implementazione piuttosto che estrarre il codice in un metodo o la sua classe e chiamarlo invece. Le chiusure possono anche migliorare la riusabilità - dipende solo da come le usi.

In molti casi le funzionalità disponibili modellano il modo in cui strutturi il 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ù la capacità di fornire il riutilizzo del codice di quanto un montascale o altre attrezzature per il fitness possano portare alla perdita di peso. Gli sviluppatori devono essere motivati ​​a utilizzare correttamente gli strumenti.

Una volta che i team di software attribuiscono un valore maggiore al riutilizzo del codice testato rispetto a quando mantengono tutti i dettagli nella loro testa, vedrai oggetti e metodi molto più dettagliati e quindi un maggiore riutilizzo del codice.

sì

OOP ti offre più modi per riutilizzare il codice

No

non c'è proiettile d'argento

Dipende

su cosa ci hai messo e cosa ti aspettavi in ​​cambio!

Sì. Una buona programmazione orientata agli oggetti promuove la separazione delle preoccupazioni, il basso accoppiamento, l'alta coesione e il nascondimento delle informazioni. Queste cose sono tutte fondamentali per il codice riutilizzabile.

Direi che il vantaggio principale di OOP è la modularità e la modificabilità, piuttosto che il riutilizzo, ma questa è un'altra domanda.

Gli oggetti abilitano il ricorso al 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 capacità di estendere (ereditare) da una super classe chiaramente contribuisce al riutilizzo del codice, non sono sicuro di come si possa discutere diversamente. Puoi semplicemente estendere una classe e sovrascrivere un metodo, mentre usi il resto dalla super classe, se questo non aiuta il riutilizzo del codice, allora non so cosa sia

Se lo è, hanno mantenuto la promessa di riutilizzare il codice finora? Sì, se i programmi scritti pensando a OOP applicano saggiamente i modelli di progettazione. Altrimenti, per lo più no. Ma osservando la popolarità di programmi non banali su larga scala che sistemi Adobe, Google e simili scrivono con C ++ o Java o altri linguaggi OOP, direi che OOP ha ancora molta strada da fare prima che venga eliminata. Quel tempo sarà molto più adatto a porre questa domanda e potrebbe aiutare a fornire lavoro di base per un nuovo paradigma.