Nella mia attuale azienda abbiamo portato la discussione su come organizzare la maggior parte dei nostri diversi componenti C ++ considerando i seguenti requisiti:
- Potrebbero esserci interdipendenze tra i componenti
- I componenti con dipendenze di terze parti molto specifiche / oscure non sono inclusi in questo esercizio
- Non tutti i progetti hanno bisogno di ogni componente, solo un piccolo sottoinsieme di essi
Ci sono fondamentalmente due scuole di pensiero (almeno all'interno dell'azienda) su come organizzare tutti i componenti:
- Il primo crede che dovremmo raggruppare tutti i componenti insieme in un'enorme libreria (che può essere composta da più di un oggetto condiviso e consentire il collegamento a ciò di cui un progetto ha bisogno, ma in termini di installazione e compilazione è tutto insieme) .
- Il secondo crede che dovremmo creare una libreria per componente e mantenerli totalmente separati (ognuno di essi è installato separatamente e include tutti gli oggetti condivisi di cui hanno bisogno).
Riesco a vedere molti aspetti positivi e negativi per entrambi gli approcci e personalmente non credo che nessuno di essi sia giusto o sbagliato, ma mi piacerebbe avere un po 'più di intuizione da parte di coloro che hanno sperimentato con entrambi gli approcci e in grado di supportare con i fatti l'uso di un approccio sull'altro.
Modifica: essere più specifici sui problemi.
- Come gestiresti le dipendenze della versione tra un approccio "molte piccole librerie"?
- Come si evita di avere un casino di interdipendenze tra oggetti quando si ha un approccio massivo alla libreria?
- Quali tipi di problemi di prestazioni potrebbero causare ogni approccio nei sistemi Windows e Linux, quando si collegano staticamente o dinamicamente? Che tipo di benefici?
- Qualche altro commento che potrebbe essere utile per decidere quale approccio seguire?