Mantenimento dell'indipendenza tra i moduli

No, il punto è che per utilizzare una specifica libreria, tutto ciò che devi sapere a riguardo dovrebbe essere nella sua interfaccia pubblica (in C ++, tipicamente il file di intestazione). Dovresti non dover sapere qualcosa di altro rispetto a questo, in particolare non qualcosa su quali algoritmi, tipi di dati, variabili ecc. Esistano all'interno della libreria. Se lo sapessi, potresti iniziare a fare affidamento su queste informazioni e verrai bruciato quando l'implementazione della libreria viene cambiata un giorno.

È abbastanza comune che l'uso di una libreria richieda di includere più intestazioni da altre librerie - ad esempio, utilizzando una libreria HTTP potrebbe essere necessario importare le definizioni di richiesta o le definizioni di pacchetto che l'HTTP la libreria stessa utilizza nella sua API. Ma non dovrebbe richiedere di importare una struttura dati LinearTrie semplicemente perché la libreria HTTP ne usa uno nel suo codice privato.

No, non è così.

Significa che la libreria di rete è composta da due parti. Un'API, che definisce il modo in cui il codice deve comunicare con questa libreria e una parte di implementazione, che esegue la libreria. E che il tuo codice dovrebbe dipendere solo dalla parte API e non dovrebbe dipendere, sia direttamente che in modo transitorio dalla parte di implementazione. Il vantaggio di questo tipo di progettazione è la possibilità di modificare facilmente il funzionamento interno della libreria, senza doversi preoccupare di rompere il codice che utilizza questa libreria.

In realtà è in qualche modo difficile farlo in C ++, perché se si tenta di utilizzare i file di intestazione come API, quindi devono contenere i dettagli di implementazione della libreria in forma di membri privati. E se si tenta di avere due "sottolibrerie", la pipeline di compilazione del codice che utilizza questa libreria separata diventa molto più complicata. E non parliamo di come sarebbe la gestione della memoria in questo caso.