Ho un front-end C # che deve chiamare un back-end C ++. Quindi è necessario l'interop.
Ho un "livello di interoperabilità", che converte la struttura di dati C # in una struttura C ++ e fa tutto il lavoro di liberazione da grunt della memoria.
La mia domanda è, dovrei scrivere questo livello di interoperabilità come una classe statica , o dovrei avvolgerlo in una classe normale e istanziarlo come un oggetto quando devo usarlo?
static (in particolare le classi statiche) dovrebbe essere evitato il più possibile, IMO. Il risultato è un codice inflessibile e difficile da testare. Una corretta classe normale ti consentirebbe anche di eseguire alcune operazioni di inizializzazione o pulizia (tramite IDisposable ) se necessario, e potresti facilmente passare a un'interfaccia per utilizzare la simulazione o sostituire il back-end con una gestita.
Sicuramente andrei con una classe non statica. Ciò ti consente di implementare IDisposable e ripulire le tue risorse non gestite nel modo. NET preferisce.
Se stai facendo TDD, potresti leggere questo articolo dal Google Testing blog .
Mi è piaciuta molto la seguente citazione dell'articolo, che riassume molto bene il problema:
The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to "wire" since there are no objects, the code and data are separate.