Coerenza contro usabilità? [chiuso]

Credo di essere fortunato perché non ho mai dovuto fare una scelta del genere, dato che il modello condiviso scelto di solito è già il più amichevole.

Tuttavia, se dovessi scegliere, andrei con consistency : ciò semplifica le operazioni di debug e rende più chiara la comunicazione all'interno del team.

Direi addirittura che un'API coerente fa parte di ciò che lo rende utilizzabile.

Vorrei provare ad essere sia coerente che utilizzabile.

Se la coerenza ostacola l'usabilità (dove un'API può essere ottimizzata come hai detto), offri una nuova classe, funzione o libreria wrapper che faccia proprio questo. Assicurati solo di commentare / documentare il codice che è ovvio come ogni funzione è correlata.

È come sovraccaricare i costruttori. Certo, quello con 3 parametri è più coerente e flessibile, ma forse il costruttore con un solo parametro è usato più spesso nella tua applicazione.

Quindi la tua libreria sarà flessibile (come ha sottolineato Jeremy) e utilizzabile come vorresti che fosse per il normale uso.

Vorrei andare con consistency me stesso. I tuoi clienti possono sempre scrivere wrapper nella tua libreria per renderli più facili da usare o rimuovere la duplicazione.

Potresti anche fornire un'altra API accanto a quella principale che include l'API principale per loro in modo che possano usarla per i casi più comuni.

Trovo che spesso favorire l'usabilità riduca la flessibilità di quella parte dell'API, perché ora è adattata al caso speciale.

Ci sono più dimensioni di design. Essere pedante (e ottimizzato):

• Consistente : operazioni simili appaiono simili tra le interfacce
• Utilizzabile : l'API risolve la maggior parte dei problemi degli utenti con un piccolo file di testo aggiunto
• Semplice : le operazioni esprimono un singolo intent (probabilmente possono essere riassemblate in modo utile dal client)
• Incapsulato : l'API espone un'interfaccia minima (massimizzando quale implementazione può cambiare senza rompere i chiamanti)

La scelta del design dovrebbe dipendere dal modo in cui la tua API interagisce con il resto del sistema, "livello" (basso / alto) della tua API, quanto è ben definito il problema, ecc.

Se stai progettando qualcosa che assomiglia molto alle API esistenti, in particolare le API di sistema, la coerenza è probabilmente più importante dell'usabilità. Come altri hanno già detto, l'usabilità potrebbe essere sovrapposta come API separata. Probabilmente l'API di livello superiore dovrebbe essere progettata per l'usabilità.

Le API di basso livello dovrebbero concentrarsi sulla semplicità poiché potrebbero essere potenzialmente utilizzate da molte API di livello superiore. Essere in grado di combinare le chiamate in modi diversi è importante.

L'incapsulamento è particolarmente importante se il problema non è ben esplorato. L'esposizione di un sacco di un'interfaccia sperimentale richiede di avere un sacco di codice client danneggiato (o di dover mantenere il codice legacy) se si deve modificare il progetto. In questo caso, può avere senso ignorare la semplicità / consistenza e invece esporre solo il minor numero possibile di funzioni.