In realtà direi che in alcuni casi, potrebbe essere meglio non ossessionare il riutilizzo del codice e concentrarsi invece sulla scrittura del codice nel modo più semplice possibile. Troppe funzioni complesse come la sottoclasse, le interfacce astratte implementate ovunque, ecc. Significano che è quasi impossibile fare qualsiasi debugging utile. Anche la troppa astrazione può essere la causa dei problemi di prestazioni.
Veloce: qual è il vero tipo di dati dell'oggetto che hai e cosa fa quando chiami un particolare metodo? Il problema è che potresti non necessariamente saperlo. E nei casi in cui potresti saperlo, potrebbe essere necessario molto tempo per ottenere tali informazioni.
Se la soluzione naturale per un problema è un'interfaccia che si implementa, si prega di utilizzare le interfacce. Non metterli ovunque, tuttavia, solo per mantenere basso il numero di code line. La sottoclasse potrebbe essere a volte una soluzione naturale, ma il più delle volte si dovrebbe preferire la composizione sull'ereditarietà e le interfacce potrebbero essere un'idea migliore delle sottoclassi in cui tale regola non si applica.
Ho lavorato a un progetto in cui abbiamo implementato un servizio online piuttosto complesso utilizzando un codice semplice. Codice non condiviso-ovunque. Non cercare di mantenere basso il LoC. Semplice codice, e molto. Scrivere un nuovo codice era veloce: mentre un programmatore esperto può scrivere 1000 righe di codice complesso al mese, potremmo scrivere oltre 10000 righe di codice semplice al mese per sviluppatore. Il debug è stata una gioia totale. Puoi quasi sempre vedere che cosa fa un determinato pezzo di codice, perché non tutto è stato distrutto da un'interfaccia. Le query SQL sono state costruite manualmente, pertanto è possibile testare facilmente le loro prestazioni nel database e visualizzare il piano di query utilizzando EXPLAIN . Abbiamo condiviso il codice? Certo che lo abbiamo fatto, avevamo un codice condiviso, ma lo usavamo solo quando aveva senso, non tentando di mantenere il LoC abbassato a tutti i costi. Abbiamo anche utilizzato le librerie esterne ovunque avesse senso. Un sacco di volte, in realtà aveva senso implementare la funzionalità da soli invece di scegliere una libreria esterna per un lavoro da 100-LoC.
Suggerirei che se si desidera mantenere basso il LoC, è necessario creare due misure: il LoC delle parti che sono state scritte e il LoC di tutto il software da cui dipende. Considera che c'è 1 bug per 100-10000 LoC (forse 1 bug per 100 LoC per codice complesso, 1 bug per 10000 LoC per codice semplice). Quindi, se hai due milioni di LoC in componenti esterni, quanti bug hai? Duecento? Duemila? Ventimila? Solo per il gusto di farlo, prova a vedere se il codice esterno è semplice o complesso guardandolo. Scommetto che è complesso, non semplice.