Motivazione per le API ottimizzate?

Question

Sembra che ci sia una discreta quantità di antipatia da queste parti per le API orribilmente ingegnerizzate che sono progettate per essere infinitamente flessibili e quindi non semplificano le cose semplici. Tuttavia, sembra che non vi sia carenza di API che richiedono l'utilizzo di 8 classi diverse e la scrittura di 20 righe di boilerplate solo per eseguire compiti semplici e comuni. Non menzionerò i nomi perché questo non dovrebbe essere un flamewar sul fatto che le API specifiche siano sovrastampate.

Quale credi sia la causa principale di queste API orribilmente ipovedificate? Cosa pensi che debba accadere per evitare che i progettisti API creino tali mostruosità?

Modifica: IMHO, nemmeno la creazione di codice riusabile è davvero una buona risposta perché se l'API è ridicolmente difficile da usare e richiede tonnellate e tonnellate di caldaia, i vantaggi del riutilizzo diventano discutibili.

Answer 1

Non credo che nulla possa impedire alle persone di pensare troppo a problemi. È inerente alla risoluzione dei problemi. Metodologie come XP cercano di scoraggiarlo, ma quando si arriva a questo, tutti pensano "Ma se lo faccio più generico, allora posso riutilizzarlo in tale e così"

Answer 2

"L'ottimizzazione prematura è la radice di tutto il male."
--Don Knuth

Anche così, è molto, molto allettante perché i programmatori istintivamente come l'efficienza e intelligenza.

Answer 3

Secondo effetto di sistema?

Answer 4

La radice di tutti i mali è che gli sviluppatori non sono a) intelligente/esperto eb) sufficientemente adeguato.

Answer 5

Credo che questo sia spesso una conseguenza del cosiddetto Second System Effect. I progettisti prendono le lezioni apprese dal loro primo taglio del design "versione 1", e rendono la versione successiva molto più flessibile da diventare eccessivamente ingegnerizzata e difficile da capire.

Il libro di Fred Brooks The Mythical Man-Month ha introdotto questo termine e ne parla in dettaglio.

Answer 6

Non sono sicuro che si tratti di un'ingegneria eccessiva o di un'astrazione insufficiente. Windows API è un ottimo esempio di questo.

Una volta ho passato un bel po 'di tempo a scrivere un motore di stampa e di anteprima. Ho dovuto decodificare le chiamate api di Windows necessarie per visualizzare le cose sullo schermo e l'output su una stampante. Nel creare l'astrazione api ho cercato di pensare in termini di ciò che lo sviluppatore sta cercando di realizzare ... ad esempio: "Voglio disegnare un 1 punto di larghezza, linea rossa dalle coordinate (1, 1) a (8, 1) - espresso in pollici. "

l'equivalente api di Windows per questo comporta molte, molte linee di codice irritanti ... creare un pennello, selezionarlo in un contesto di dispositivo, impostare il punto di partenza, gestire le conversioni da pollici a pixel, disegnare a un punto finale , ecc. la mia API astratta è una singola chiamata: dpLine (documentHandle, x1, y1, x2, y2, width, color); // dove x1, x2, y1, y2 sono espressi in pollici

In questo caso, penso che Windows gdi api sia di livello troppo basso. Sono sicuro che ci sono buone ragioni per le cose che hanno fatto e semplicemente non hanno tempo/energia per creare un'interfaccia corretta per i programmatori che probabilmente lo useranno. La ragione della mostruosità è probabilmente solo scadenze temporali.L'api è tecnicamente accurata; consente a un programmatore di fare ciò di cui ha bisogno. Questo è abbastanza buono per spedirlo. Ma è così basso che sono necessarie astrazioni di terze parti per renderlo utilizzabile. IMO, puoi creare un argomento per un sistema operativo per fornire una api complicata di basso livello come questa, ma uno strumento di terze parti non dovrebbe essere così complicato.

-Don

Answer 7

Penso che Python abbia sofferto di Second System Effect. Nella versione 2.x esistono due tipi di classi e semantica diversa.

Speriamo che Python 3.0 risolva la maggior parte di questo.