¿Motivación para las API Overengineered?

Question

Parece que aquí hay una cantidad de aversión decente por las API horriblemente sobredimensionadas que están diseñadas para ser infinitamente flexibles y por lo tanto no simplifican las cosas simples. Sin embargo, parece que no hay escasez de API que requieran el uso de 8 clases diferentes y escribir 20 líneas de texto repetitivo solo para realizar tareas simples y comunes. No mencionaré nombres porque se supone que esto no es una guerra de llama sobre si las API específicas son sobreinyectadas.

¿Cuál cree que es la causa raíz de estas API horriblemente sobredimensionadas? ¿Qué crees que debe suceder para evitar que los diseñadores de API creen tales monstruosidades?

Edit: En mi humilde opinión, ni siquiera la creación de código reutilizable es realmente una buena respuesta porque si la API es ridículamente difícil de usar y requiere toneladas y toneladas de repetición, los beneficios de la reutilización se vuelven cuestionables.

Answer 1

No creo que nada pueda evitar que las personas tengan problemas de pensamiento excesivo. Es inherente a la resolución de problemas. Las metodologías como XP intentan desalentarla, pero cuando se trata de eso, todos piensan "Pero si hago esto más genérico, entonces puedo reutilizarlo en tal o cual"

Answer 2

"La optimización prematura es la raíz de todo mal".
--Don Knuth

Aun así, es muy, muy tentador porque los programadores instintivamente como la eficiencia y la inteligencia.

Answer 3

Segundo efecto del sistema?

Answer 4

La raíz de todo mal es que los desarrolladores no son a) inteligente/experimentado yb) lo suficientemente adecuado.

Answer 5

Creo que esto es a menudo una consecuencia del llamado Second System Effect. Los diseñadores toman las lecciones aprendidas de su primer corte del diseño de "versión 1", y hacen que la próxima versión sea mucho más flexible para que sea más compleja y difícil de entender.

El libro de Fred Brooks The Mythical Man-Month introdujo este término y lo menciona en detalle.

Answer 6

No estoy seguro de si se trata de un caso de exceso de ingeniería o de abstracción insuficiente. La API de Windows es un buen ejemplo de esto.

Érase una vez que pasé una buena cantidad de tiempo escribiendo un motor de impresión y vista previa. Tuve que decodificar las llamadas de API de Windows necesarias para mostrar cosas en la pantalla y enviarlas a una impresora. Al crear la abstracción api intenté pensar en términos de lo que el desarrollador está tratando de lograr ... por ejemplo: "Quiero dibujar una línea roja de 1 punto desde las coordenadas (1, 1) a (8, 1) - expresado en pulgadas ".

la API equivalente para esto implica muchas, muchas líneas irritantes de código ... crear un pincel, seleccionarlo en un contexto de dispositivo, establecer el punto de partida, manejar las conversiones de pulgadas a píxeles, dibujar a un punto final , etc. mi API abstraída es una sola llamada: dpLine (documentHandle, x1, y1, x2, y2, ancho, color); // donde x1, x2, y1, y2 se expresan en pulgadas

En este caso, creo que la API de Windows gdi es demasiado baja. Estoy seguro de que hay buenas razones para las cosas que han hecho y simplemente no tienen tiempo/energía para hacer una interfaz adecuada para los programadores que puedan usarla. La razón de la monstruosidad es probablemente solo las fechas límite.La API es técnicamente precisa; le permite a un programador hacer lo que necesita. Eso es lo suficientemente bueno para enviarlo. Pero, es un nivel tan bajo que las abstracciones de terceros son necesarias para hacerlo utilizable. OMI, puede presentar un argumento para que un sistema operativo proporcione una API complicada y de bajo nivel como esta, pero una herramienta de terceros no debería ser tan complicada.

-Don

Answer 7

creo que sufría de Python segundo efecto del sistema. En la versión 2.x existen dos tipos de clases y semántica diferente.

Esperemos que Python 3.0 resuelva la mayor parte de esto.