Cosa scegliere, interfaccia ioctl-like o un insieme di metodi distinti?

Question

Cosa scegliere, interfaccia ioctl-like o un insieme di metodi distinti?

#1 da (5 voti)

2

Sto implementando un protocollo di messaggistica tra i nodi su una rete e mi chiedo come esporre l'interfaccia del sistema di messaggistica ai programmatori. Il protocollo di messaggistica supporta un insieme di comandi che i client e i server possono scambiare per portare a termine i lavori.

Per essere generico, diciamo, ad esempio, il sistema supporta 2 operazioni: REQUEST_OBJECT, MODIFY_OBJECT. Per fornire un'interfaccia, ho 2 scelte: se fornire 2 metodi distinti: request_object (handle, obj) e modify_object (handle, obj, data) o utilizzare un metodo generico: msg_ioctl (handle, COMMANDE, var_args ...) , il numero di argomenti variadici var_args ... e la loro interpretazione dipende esclusivamente da COMMANDE quindi in questo caso avremo 2 casi diversi per la chiamata ioctl: msg_ioctl (handle, REQUEST, obj) e msg_ioctl (handle, MODIFY, obj, data) .

Quali sono i vantaggi e gli svantaggi di ciascuna opzione e quali potrebbero essere i possibili difetti che possono diventare visibili a lungo termine prendendo in considerazione diversi linguaggi che potrebbero essere utilizzati (Per discutere di argomenti come il controllo del tipo di argomento ... ecc. ) per implementare un tale sistema?

design api-design interfaces protocol message-passing

posta Karim Manaouil 06.10.2018 - 23:16

fonte

1 risposta

Leggi altre domande sui tag design api-design interfaces protocol message-passing

Documentare la causa del bug Devo spostare le attività che sono solo per un elemento specifico solo per ciclo chiuso?

score 5 · Accepted Answer

Whether to provide 2 distinct methods : request_object (handle, obj) and modify_object (handle, obj, data) or use a generic method : msg_ioctl (handle, COMMANDE, var_args ...)

Utilizza il primo: due metodi distinti.

Nel software, l'interfaccia client consumante è fondamentale. Mentre l'approccio IOCTL ha (probabilmente) alcuni vantaggi di implementazione, l'approccio distinto dei metodi ha grandi vantaggi per il consumatore consumatore.

IOCTL essenzialmente mischia molte operazioni insieme, mentre l'altro le tiene in sordina.

Tenuti a parte, l'IDE, la ricerca, ecc. sono più efficaci. Questo supporta meglio il refactoring e la manutenzione dei client che utilizzano l'API.

Molte cose funzionano meglio quando i metodi vengono mantenuti distinti, come il sistema di tipi - la nostra prima linea di difesa contro i bug. Per un altro, il compilatore genererà quasi sicuramente un codice migliore sui siti di chiamata per i metodi separati (con parametri dichiarati distintamente) piuttosto che per un singolo metodo che utilizza vararg.

In sintesi, non dovremmo confondere cose altrimenti distinte Non posso pensare a nessun vantaggio reale per farlo in questo caso (a parte il vantaggio di implementazione estremamente minore di fornire un metodo in meno per l'API, e anche assumendo che l'implementazione si gira e crea un simile syscall (stile IOCTL).