¿Cuál es el principio de menor asombro?

En la programación, ¿qué se llama Principio de Menos Asombro? ¿Cómo se relaciona este concepto con el diseño de buenas API? ¿Es esto algo aplicable solo a la programación orientada a objetos o también impregna otras técnicas de programación? ¿Está relacionado con el principio de "hacer una sola cosa en su método y hacerlo bien"?

El Principio de Menos Asombro es aplicable a una amplia gama de actividades de diseño, y no solo en informática (aunque a menudo es donde ocurren las cosas más sorprendentes).

Considere un elevador con un botón al lado que dice "llamar". Cuando presiona el botón, suena el teléfono público (en lugar de llamar al ascensor a ese piso). Esto se consideraría sorprendente. El diseño correcto sería colocar el botón de llamada al lado del teléfono en lugar del elevador.

A continuación, piense en una página web que tiene una ventana emergente que muestra un error de estilo de Windows con un botón 'ok'. La gente hace clic en el botón 'ok' pensando que es para el sistema operativo y en su lugar va a otra página web. Esto asombra al usuario.

Cuando se trata de una API ...

• Piense en un método toString () que en lugar de imprimir los campos devuelve "para ser implementado".
• Un método equals () que funciona con información oculta.
• A veces, las personas intentan implementar una clase de lista ordenada cambiando el método add para llamar a sort () en la matriz después, lo cual es sorprendente porque se supone que el método add se agrega a la lista, esto es especialmente sorprendente cuando uno recupera un objeto List sin saber que en algún lugar en el fondo, alguien violó el contrato de interfaz.

Tener un método que haga una cosa distinta contribuye a reducir el asombro, sin embargo, estos son principios separados en el diseño de API. Los cuatro principios a menudo promocionados como "buen diseño de API" son (de este pdf , solo una instancia de tal presentación. Los enlaces al final de este particular hacen una buena lectura):

• Principio de responsabilidad única
• Principio abierto cerrado
• SECO
• Principio de mínimo asombro

Es potencialmente sorprendente que alguien tenga una clase que intente hacer todo, o que necesite dos clases para hacer una sola cosa. También es potencialmente sorprendente que alguien se meta con los elementos internos de manera extraña debajo de las sábanas (creo que las clases abiertas en Ruby son una fuente de asombro interminable). También es sorprendente encontrar dos métodos que aparentemente hacen lo mismo.

Como tal, el principio de menor asombro subyace a los otros diseños de API, pero, en sí mismo, no es suficiente para decir simplemente "no tenga una API sorprendente".

Lecturas adicionales (desde la perspectiva de la interfaz de usuario): un blog para desarrolladores de IBM titulado El usuario malhumorado: El principio del menor asombro

El principio de menor asombro es cuando usted, como diseñador de API, evita que sus usuarios digan WAT .

Algunos ejemplos de asombro en varios idiomas.

var array=new string[]; 
var list=array as IList<string>; //this works... 
list.Add("foo"); //exception saying it's not supported

foo.Equals(bar); //will call overriden Equals method
foo == bar; //equivalent to above in everyway, except for it won't call overrides... unless you're dealing with a string

var d=DateTime.Today;
d.Add(new TimeSpan(36,0,0,0)); //add 36 days to datetime d
Console.Writeline(d); //will print todays date. WAT

//in javascript
var f=function(){
  return 
    10; 
} //will either throw a syntax error or return void, depending on your javascript runner

Y hay muchos más ejemplos en varios idiomas y API. Su trabajo como escritor de API es evitar esto. Las cosas deben nombrarse y escribirse de tal manera que sea obvio lo que hará una llamada a su API. Incluya una amplia documentación donde esto no sea posible.

Básicamente, si la gente tiene que leer su documentación a fondo para descubrir cómo LEER el código escrito para su API, probablemente lo esté haciendo mal.

Aquí hay un ejemplo de "asombro" que me sucedió recientemente. Me perdí en el camino, así que me detuve y un tanto frenético (llegué tarde) golpeé una intersección en mi GPS. Hice clic en Ir y puse mis manos nuevamente en el volante, pero luego recibí una fuerte advertencia (pantalla completa) de que el GPS debería actualizarse, lo que me obliga a reconocer.

Mi pensamiento fue "¿estás bromeando? ¿Me estás diciendo esto ahora? ¿Necesito quitar mis manos del volante para reconocerlo?".

El asombro aparece en la interfaz (generalmente la interfaz de usuario, pero supongo que también podría ser una API que se comporta de manera inesperada). Yo diría que también penetra por debajo de la interfaz, porque se necesita un software subyacente bien diseñado para admitir una interfaz realmente bien diseñada.