Che cosa significa la seguente definizione di interfaccia?

I linguaggi OOP lo fanno molto meglio, e anche in C ci sono modi migliori per farlo, ma qui c'è un esempio grezzo. Mostrerò un'interfaccia solo con i metodi - il concetto di ricezioni di eventi è più complesso, ma ortogonale a quello delle interfacce, e anche accanto a metodi e ricezioni di eventi ci possono essere altre cose che l'implementazione dell'interfaccia deve soddisfare, e io posso ' t mostrali tutti qui (sicuramente non in C!)

#include<stdio.h>

typedef struct {
    /// Prints a key-value pair, where value is an integer
    void (*printIntItem)(char key[], int value);
    /// Prints a key-value pair, where the value is a string
    void (*printStringItem)(char key[], char value[]);
} PrintInterface;


void json_printIntItem(char key[], int value) {
    printf("{\"%s\": %d}\n", key, value);
}
void json_printStringItem(char key[], char value[]) {
    printf("{\"%s\": \"%s\"}\n", key, value);
}
PrintInterface PrintJson() {
    PrintInterface interface;
    interface.printIntItem = json_printIntItem;
    interface.printStringItem = json_printStringItem;
    return interface;
}


void xml_printIntItem(char key[], int value) {
    printf("<%s>%d</%s>\n", key, value, key);
}
void xml_printStringItem(char key[], char value[]) {
    printf("<%s>%s</%s>\n", key, value, key);
}
PrintInterface PrintXml() {
    PrintInterface interface;
    interface.printIntItem = xml_printIntItem;
    interface.printStringItem = xml_printStringItem;
    return interface;
}


void printStuff(PrintInterface implementation) {
    implementation.printIntItem("one", 1);
    implementation.printStringItem("two", "2");
}

int main() {
    PrintInterface jsonImpl = PrintJson();
    printStuff(jsonImpl);

    PrintInterface xmlImpl = PrintXml();
    printStuff(xmlImpl);
    return 0;
}

PrintInterface è l'interfaccia. Ha due metodi: printIntItem e printStringItem . Il loro contratto può essere diviso in due parti:

• Contratto esplicito - può essere applicato dalla lingua. Questa è la firma, ciò che accettano e ciò che restituiscono. Alcune lingue consentono di aggiungere più cose da applicare in questo contratto, ad es. quali eccezioni (errori) possono essere generate, come il metodo può interagire con altri dati, ecc. In questo caso tutto ciò che viene applicato è che i metodi accettano due argomenti - una stringa e una stringa / int - e non restituiscono nulla.
• Contratto implicito - la documentazione, compreso ciò che può essere compreso dai nomi dei metodi e dai nomi dei loro argomenti. Il linguaggio non può far rispettare questo, quindi spetta al programmatore rispettare. È quasi sempre una cattiva idea ignorare quella parte del contratto - se l'autore si preoccupa di scrivere qualcosa nella documentazione di solito per un motivo, e anche gli utenti dell'interfaccia si aspettano che il contratto sia rispettato.

Ho anche scritto due implementazioni - PrintJson e %codice%. Quello che fanno è semplicemente mettere le funzioni dentro a PrintXml struct. I linguaggi / le librerie OOP corretti hanno molto di più modi efficienti e convenienti per farlo, ma questo è per il gusto di essere facile da seguire. Entrambi restituiscono un valore dello stesso tipo - PrintInterface - e quel tipo può essere passato agli utenti dell'interfaccia, come PrintInterface .

Quando si esegue questo programma, questo verrà stampato:

{"one": 1}
{"two": "2"}
<one>1</one>
<two>2</two>

Il primo printStuff viene chiamato con l'implementazione JSON. Utilizza l'API per stampare la coppia chiave-valore printStuff e quindi la coppia chiave-valore "one"->1 , e quindi "two"->"2" e {"one": 1} vengono stampati perché utilizza un'implementazione JSON.

Quindi viene chiamato {"two": "2"} con l'implementazione XML. Utilizza l'API per stampare la coppia chiave-valore printStuff e quindi la coppia chiave-valore "one"->1 , e quindi "two"->"2" e <one>1</one> vengono stampati perché ora utilizza un'implementazione XML.

Questo tipo di interfaccia è un concetto che non funziona molto bene al di fuori di un linguaggio almeno minimamente orientato agli oggetti.

Nel senso orientato agli oggetti, l'interfaccia sarà una classe su queste linee:

class/interface IEatable {
  public mustOverride void eatMe();
}

L'idea è che se qualche altra classe eredita / implementa l'interfaccia, il compilatore eseguirà un adattamento a meno che non fornisca una funzione eatMe corrispondente a tale firma. E poiché sai che è il caso, puoi in seguito fare qualcosa di simile

IEatable myEatable = some_function_returning_some_eatable_subclass();
myEatable.eatMe();

Senza preoccuparsi di quale tipo di commestibile hai a che fare in quel momento, perché il compilatore si sarà assicurato che quella funzione fosse valida su qualunque oggetto rotoli giù per la pipe.

Ora in C, non hai il supporto per la lingua praticamente per niente. Non è possibile dichiarare variabili che puntano a versioni leggermente diverse di quanto richiesto e non è possibile dichiarare tipi di dati che hanno funzioni incorporate. Ora probabilmente si potrebbe simulare questo comportamento con le strutture che contengono tabelle di puntatori di funzione, ma a quel punto si sta costruendo un sottosistema OO all'interno di C comunque. Questo è il genere di cose che i linguaggi OO fanno sotto il cofano, comunque.

C non supporta questo tipo di cose, in particolare perché è un concetto di OOP con un ruolo molto specifico. Penso che la spiegazione che hai ottenuto fosse molto scarsa, soprattutto perché non si parla mai del perché esistano interfacce. Quindi lo menzionerò qui.

Prima di tutto, un'interfaccia è molto simile a una classe, tranne che non puoi specificare alcuna implementazione. Qualsiasi classe che implementa un'interfaccia DEVE implementare TUTTI i metodi in essa contenuti. Questo è il modo più semplice per metterlo.

Ora un'interfaccia è un modo per designare concetti estremamente astratti che non condividono la stessa implementazione, pur mantenendo il polimorfismo. Un oggetto geometrico 2D è un esempio di qualcosa che potrebbe essere un'interfaccia. La ragione è che condividono tutti lo stesso concetto di un'area, ma il modo in cui si andrebbe a ottenere l'area dipende dalla forma specifica. Un quadrato è W H, un cerchio è pi r ^ 2, ecc. Quindi qualsiasi classe che implementa questa interfaccia sarebbe costretta ad implementare il proprio metodo di area. Un altro esempio potrebbe essere un veicolo, dal momento che tutti i veicoli hanno una proprietà simile: in movimento. Tuttavia un'auto, una barca e un aereo si muovono in modi completamente diversi.

Le interfacce sono spesso mal utilizzate. Molte persone useranno le interfacce per qualcosa che è troppo specifico. Un esempio che ho visto di recente stava usando un'interfaccia per rappresentare "alimenti congelabili". Questo è un esempio di uso improprio di un'interfaccia. Tutti i cibi posso pensare di congelare nello stesso modo. La loro temperatura viene ridotta in modo da rallentare la riproduzione dei batteri. Ora se doveva essere un "oggetto congelabile" Questo è un buon esempio di un'interfaccia, perché l'implementazione dell'acqua gelata non è la stessa cosa del congelamento della carne, né l'uno o l'altro sono uguali al congelamento dell'idrogeno (il che si traduce in un fenomeno interessante noto come super solido)

Se l'implementazione è la stessa per tutte le istanze, dovrebbe andare direttamente in una classe ed essere implementata. Inserirlo in un'interfaccia comporta la ripetizione del codice ed è un design estremamente scadente.