Sarà bene per un'interfaccia prendere dipendenza da un'interfaccia in questa situazione?

Ci sono due opzioni per questo tipo di dipendenza.

Dipendenza dell'interfaccia

È possibile definire un metodo sull'interfaccia controller che accetta un buffer. Ciò aumenta l'accoppiamento tra i moduli e può avere un effetto a catena in termini di dipendenze e modifiche al codice. Le implementazioni esistenti dovranno essere aggiornate e potrebbero non interessare al buffer.

Tutte le sottoclassi hanno un uso per il buffer? La parte "utilizza il buffer" di ciò che fa il controller? Se è così, questo può essere sensato.

Dipendenza del costruttore

Lascia le interfacce da solo e passa il buffer nel costruttore dell'implementazione. Questo evita l'accoppiamento dei moduli e l'aggiornamento delle classi esistenti.

Se solo alcune implementazioni riguardano il buffer o se è necessario limitare le modifiche tra i moduli, questa è una soluzione più efficace.

Because of how the CommonInterfaces is used all over the place, is it okay for my IEquipmentController's project to take a dependency on the CommonInterfaces project?

Certo che lo è. Questo è il punto centrale di un progetto come CommonInterfaces. Vuoi essere in grado di riutilizzare liberamente tali interfacce in una varietà di progetti.

Tuttavia, potresti prendere in considerazione la possibilità di restituire un'interfaccia più generica. Non perché si vuole evitare una dipendenza del progetto, ma perché si vuole evitare la perdita dei dettagli di implementazione. L'utente di IEquipmentController ha davvero bisogno di sapere che sta usando un ICircularBuffer ? ICircularBuffer probabilmente implementa (o dovrebbe implementare) IList . Forse ha senso restituire il buffer come elenco.