Logistica di riutilizzo del codice (OOP)

Non condivido "oggetti" tra i progetti, condivido classi che definiscono gli oggetti.

Il modo in cui viene eseguito varia: a volte costruisco una libreria compilata con classi condivise in comune tra loro. A volte copio manualmente i file tra i progetti, se si tratta solo di uno o due file e molto meno probabilità di essere riutilizzato di nuovo - sebbene se lo faccio più di due volte di solito inizio a chiedermi se dovrei aggiungere quelle classi a una libreria esistente o fare un nuovo.

Come posso trovare il codice che può essere riutilizzato? Devo conoscere il progetto. Per progetti molto grandi su cui molti sviluppatori hanno lavorato per anni, sì, è successo una o due volte quando inizio a creare nuove funzionalità, solo che mi hanno fatto notare che esiste già. Come "individuabile" la funzionalità preesistente dipende in realtà dagli sviluppatori precedenti e quanto bene hanno documentato ciò che hanno fatto. Migliore è la documentazione, meno probabile è che in seguito qualcuno non riesca a trovare le classi preesistenti.

Le classi riutilizzabili di un'azienda sono come qualsiasi altra libreria del fornitore e dovrebbero essere trattate allo stesso modo. L'unica differenza è come vengono create le nuove versioni.

Se un progetto che utilizza quella libreria scopre un bug, o il progetto ha semplicemente bisogno di una nuova funzionalità che avrebbe senso essere lì, allora il codice della libreria può essere modificato localmente nel progetto.

Successivamente, quando la modifica viene eseguita di nuovo senza intoppi, è possibile generare una nuova versione della libreria, applicando tutte le modifiche necessarie al repository della libreria.

A questo punto, la nuova versione dovrebbe essere pubblicata per tutti gli sviluppatori dell'azienda in modo che possano decidere se aggiornare qualsiasi progetto che utilizza una versione precedente.

Ad esempio, nei miei progetti PHP, quella libreria è memorizzata come un fratello della libreria Zend Framework nella directory libreria / venditore e condivide la stessa convenzione di denominazione in modo tale che lo stesso autoloader possa essere utilizzato per entrambi.

Dipende davvero dal codice condiviso.

Se è una funzionalità comune che è generale e potrebbe essere utile per vari progetti come come gestire i caricamenti di file o come misurare la distanza tra i punti. O operazioni comuni come la manipolazione di stringhe o strutture di dati comuni come una coda asincrona simultanea. Quindi credo che il metodo preferito sarebbe quello di portarlo fuori come un progetto diverso e costruire una libreria comune.

Alcuni notevoli esempi Java possono essere trovati in molti grandi progetti, ad esempio:

• I comuni di Apache sono utilizzati da molti progetti diversi.
• Guava è utilizzato in molti posti in Google.
• Twitter commons è ciò che Twitter utilizza nei progetti.

Ci sono molti esempi di questo tipo ...

Se d'altra parte il codice riutilizzato è molto più specifico, come in un servlet che esegue l'autenticazione e si interfaccia con i protocolli di proprietà dell'azienda. Consiglierei la modularizzazione dei 5 progetti in modo che dipendano dallo stesso sottoprogetto e nel proprio ambiente di sviluppo è possibile mantenere i progetti che si desidera verificare e fare in modo che si facciano riferimento tra loro (con gli IDE più moderni).

Quindi nel secondo caso avresti (sto usando java jars ma sarà lo stesso per qualsiasi cosa):

 + project1.jar
 + project2.jar
 + project3.jar

E lo cambieresti:

 + project-core.jar
   |- project1.jar
   |- project2.jar
   |- project3.jar

1) Innanzitutto, il riutilizzo del codice non è fine a se stesso. Ricorda che il riutilizzo del codice implica una maggiore dipendenza. se il codice che viene riutilizzato non è stabile (significa che le funzioni o le correzioni vengono ancora aggiunte ad esso) significa che potrebbe influenzare tutte le posizioni che dipendono da esso

2) Se una parte di codice non viene scritta dall'inizio con la riusabilità in mente, è molto improbabile che tu possa isolarla indietro.

3) un componente riutilizzabile dovrebbe avere poca o nessuna dipendenza esterna. Dovrebbe avere una propria suite di test, dovrei riuscire a scaricarla / controllarla dal repository, crearla ed eseguire la suite di test da sola

Quindi è un po 'più complicato che solo riutilizzando alcune classi in altri progetti, se lo fai, non puoi farlo a malincuore; hai bisogno di andare fino in fondo. Se "riutilizzi" copiando in altri progetti, non è riutilizzato, ma copia & incolla la programmazione

For example lets say you have 5 projects you have worked on and between them you have a ton of objects that you think would be useful in other projects.

Questo non è il riutilizzo del codice con cui OOP aiuta. È complesso e difficile, indipendentemente dal processo di progettazione che segui.

Il riutilizzo del codice OOP riguarda l'ereditarietà.