Organizzazione dei componenti C ++ [chiuso]

0

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?
posta AnilM3 11.02.2015 - 23:08
fonte

2 risposte

2

Nella nostra azienda, la linea di demarcazione tra l'approccio uno e l'avvicinamento due arriva alle dipendenze esterne del / i componente / i . Ad esempio, abbiamo centinaia di componenti "core" senza dipendenze di alcun genere e quelli sono raggruppati in un'unica libreria. D'altra parte, l'unico componente che usiamo per parlare con un tipo specifico di database ha la sua libreria. Allo stesso modo, disponiamo di una libreria per il nostro framework di servizi interni, una libreria per il nostro framework di registrazione interna e così via, dal momento che tali librerie dipendono dai framework installati sui computer di destinazione.

    
risposta data 11.02.2015 - 23:31
fonte
0

Dovresti tenere d'occhio due aspetti qui:

  1. Il primo è come i componenti che non è possibile modificare sono già disposti. Componenti di terze parti o alcuni componenti legacy che non desideri più modificare
  2. Componenti scritti da te o dalla tua azienda, che possono essere uniti o divisi

Una delle mie migliori pratiche al momento di decidere come dividere qualsiasi codice nei pacchetti è lasciare che il progresso stesso decida come sarebbe meglio per me. Ciò significa, per esempio, iniziare un gioco che necessiterà di boost, opengl, openal e opencl. Forse stai pensando a un componente del motore che carica risorse e così via.

Sicuramente non inizierai con gli algoritmi opencl e GPGPU o con l'audio, quindi non includere nemmeno opencl / openal nel tuo progetto in un primo momento. Andrai in questo modo usando boost e opengl per avviare il tuo progetto. Quindi noterai che stai utilizzando molte operazioni sul filesystem in diverse posizioni nel tuo codice e scrivendo troppe stringhe che vengono aggiunte per il caricamento dei percorsi di file. Sarebbe un buon inizio del tuo motore, ma non provi nemmeno a creare un sacco di file e cartelle per componenti che non implementerai immediatamente.

Come conclusione chiedi ogni nuovo pezzo di codice se ha il diritto di esistere. Poi vedrai che la domanda su come organizzare i tuoi componenti non è una domanda a cui dovresti rispondere all'inizio di qualsiasi progetto, ma ogni volta che un altro componente viene utilizzato nel progetto.

    
risposta data 12.02.2015 - 00:16
fonte

Leggi altre domande sui tag