Utilizzo delle direttive del compilatore per supportare più piattaforme

Question

Questa è una domanda di progettazione del software generale.

È una buona idea utilizzare la direttiva #IF del compilatore per supportare più piattaforme. Ad esempio, ho tre file:

IScreen.cs

public interface IScreen {
   ...
}

Screenwin.cs

#if WIN

public class Screen : IScreen {
  ...
}

#endif

Screenmac.cs

#if WIN

public class Screen : IScreen {
   ...
}

#endif

Ciò che sembra bello in questo è che posso usare BDD e avere qualcosa di simile:

Given a Screen exists with width: 1920 and height: 1080

e la schermata corretta verrebbe utilizzata in base alla direttiva del compilatore.

Sembra che otterrai anche prestazioni migliori rispetto a cercare di usare una fabbrica astratta.

Quali sono alcuni svantaggi?

Answer 1

Come ha risposto @ODED, il down-sode dell'utilizzo di directoves a tempo di compilazione è che è necessario compilare un binario specifico per ogni piattaforma. Il lato up è che non hai un'applicazione gonfia di una dimensione unica che è più grande e più lenta su ogni piattaforma solo perché è indipendente dalla piattaforma.

Un altro lato negativo di #IF è che molti strumenti di Visual Studio considerano solo il codice "attualmente attivo". Ad esempio, Strumenti di Intellisense e Refactoring - Se desiderassi rinominare iScreen in Idisplay, allora troveresti che il refactoring ha funzionato e tutto il tuo codice PC è stato aggiornato perfettamente, ma tutto il tuo codice Mac sarebbe gravemente rotto poiché gli strumenti di refactoring semplicemente non lo farebbero " Vedi "l'altro filiale del codice. Allo stesso modo, è facile apportare una modifica al codice sul ramo del PC e dimenticare di apportare la corrispondente modifica al ramo MAC, rompendolo di nuovo.

Il vantaggio di una fabbrica anziché "#if" è che una singola immagine binaria può potenzialmente essere eseguita su ogni piattaforma e devi controllare la piattaforma host solo una volta quando si crea l'implementazione concreta (quindi è ancora molto efficiente in fase di esecuzione, ma sarà più grande in quanto è necessario spedire tutte le varietà della piattaforma all'interno di una distribuzione)

Tuttavia, è possibile ottenere il meglio da entrambi i mondi utilizzando un modello di progettazione più modulare anziché #IF: utilizzare un gruppo satellitare per le implementazioni specifiche della piattaforma. In questo approccio, il codice dell'applicazione principale specificherà il IScreen interfaccia, e poi avresti concreto Screen (Mac) e Screen (PC) Classi in varianti separate specifiche della piattaforma di un gruppo imitamplementation.dll. È inoltre possibile spedire un singolo installatore che copre tutte le piattaforme (semplicemente distribuendo la DLL satellitare appropriata per la piattaforma host). Questo ti dà i miglioramenti marginali di efficienza/dimensione dell'utilizzo di #if ma senza che dover incasinare il codice con i condizionali. (Naturalmente, questo approccio modulare ha senso sia con i progetti #if e di fabbrica: diventano più un'opzione di distribuzione piuttosto che l'architettura di implementazione di base una volta divisa le implementazioni specifiche della piattaforma in assiemi separati)

Answer 2

Gli svantaggi includono il dover compilare più binari: uno per piattaforma.

Se non attento, potresti finire ingombrare il codice con la direttiva preprocessore in molte parti del codice. Vedere questo Quindi domande sull'inversione di uno di questi codebase.

Se è possibile rilevare la piattaforma all'interno del codice, è un approccio migliore.