Regole di progettazione dell'interfaccia
In questa sezione viene fornito un breve riepilogo delle regole e delle linee guida di progettazione dell'interfaccia. Alcune di queste regole sono specifiche dell'architettura COM, mentre altre sono restrizioni imposte dal linguaggio di progettazione dell'interfaccia, MIDL. Per informazioni dettagliate sulla progettazione dell'interfaccia COM, vedere Anatomia di un file IDL.
Per definizione, un oggetto non è un oggetto COM a meno che non implementi l'interfaccia IUnknown o un'interfaccia derivata da IUnknown. Inoltre, le regole seguenti si applicano a tutte le interfacce implementate in un oggetto COM:
- Devono avere un identificatore di interfaccia univoco (IID).
- Devono essere non modificabili. Una volta creati e pubblicati, nessuna parte della definizione può cambiare.
- Tutti i metodi di interfaccia devono restituire un valore HRESULT in modo che le parti del sistema che gestiscono l'elaborazione remota possano segnalare errori RPC.
- Tutti i parametri stringa nei metodi di interfaccia devono essere Unicode.
- I tipi di dati devono essere remotizzabili. Se non è possibile convertire un tipo di dati in un tipo remotable, sarà necessario creare routine di marshalling e di annullamento delmarshaing. Inoltre, LPVOID, o void *, non ha alcun significato in un computer remoto. Usare un puntatore a IUnknown, se necessario.
Nota
L'implementazione corrente di MIDL non gestisce l'overload delle funzioni o l'ereditarietà multipla.
Altre considerazioni sulla progettazione dell'interfaccia
Usare i puntatori ai dati con molta attenzione. Per ricreare i dati nello spazio indirizzi del processo chiamato, il tempo di esecuzione RPC deve conoscere le dimensioni esatte dei dati. Se, ad esempio, un parametro CHAR * punta a un buffer di caratteri anziché a un singolo carattere, i dati non possono essere ricreati correttamente. Usare la sintassi disponibile con MIDL per descrivere in modo accurato le strutture di dati rappresentate dalle definizioni dei tipi.
L'inizializzazione è essenziale per i puntatori incorporati in matrici e strutture e passati attraverso i limiti del processo. I puntatori non inizializzati possono funzionare quando vengono passati a un programma nello stesso spazio di processo, ma i proxy e gli stub presuppongono che tutti i puntatori vengano inizializzati con indirizzi validi o siano Null.
Prestare attenzione quando si esegue l'aliasing dei puntatori (consentendo ai puntatori di puntare alla stessa parte di memoria). Se l'aliasing è intenzionale, questi puntatori devono essere dichiarati alias nel file IDL. I puntatori dichiarati come nonaliased non devono mai eseguire l'alias l'uno all'altro.
Prestare attenzione a come allocare e liberare memoria. Tenere presente che, a meno che non si dica esplicitamente a un oggetto COM (usando l'attributo allocate ) di non liberare una struttura di dati creata durante una chiamata out-of-process, tale struttura verrà eliminata definitivamente al termine della chiamata. Si consideri anche il sovraccarico potenzialmente distruttivo creato dall'allocazione inefficiente delle strutture di dati che ora devono essere sottoposto a marshalling e non è stato eseguito il marshalling.
Infine, prestare attenzione quando si definiscono i valori restituiti HRESULT in modo da non creare codici di errore in conflitto con i codici di FACILITY_ITF definiti da COM (valori tra 0x0000 e 0x01FF sono riservati) o che sono in conflitto con altri valori HRESULT con lo stesso valore. Quando possibile, usare i valori restituiti di esito positivo e negativo UNIVERSAL COM e usare un parametro out, anziché HRESULT, per restituire informazioni specifiche della chiamata di funzione.
Per ulteriori informazioni, vedi gli argomenti seguenti:
Argomenti correlati