Qual é o princípio de menos espanto?

Na programação, o que é chamado de Princípio do Menos Espanto? Como esse conceito está relacionado ao design de boas APIs? Isso é algo aplicável apenas à programação orientada a objetos ou também permeia outras técnicas de programação? Isso está relacionado ao princípio de "fazer uma única coisa no seu método e fazê-lo bem"?

O princípio do mínimo de espanto é aplicável a uma ampla gama de atividades de design - e não apenas na computação (embora seja frequentemente onde as coisas mais surpreendentes acontecem).

Considere um elevador com um botão próximo a ele que diz "ligar". Quando você pressiona o botão, o telefone público toca (em vez de chamar o elevador para esse andar). Isso seria considerado surpreendente. O design correto seria colocar o botão de chamada ao lado do telefone e não no elevador.

Em seguida, pense em uma página da web que tenha uma janela pop-up que mostra um erro de estilo do Windows com um botão 'ok'. As pessoas clicam no botão 'ok' achando que é para o sistema operacional e, em vez disso, vão para outra página da web. Isso surpreende o usuário.

Quando se trata de uma API ...

• Pense em um método toString () que, em vez de imprimir os campos, retorne "a ser implementado".
• Um método equals () que trabalha com informações ocultas.
• Às vezes, as pessoas tentam implementar uma classe de lista classificada alterando o método add para chamar sort () na matriz posteriormente - o que é surpreendente porque o método add deve ser anexado à lista - isso é especialmente surpreendente quando se recupera um objeto List. sem o conhecimento de que em algum lugar profundo, alguém violou o contrato de interface.

Ter um método que faça uma coisa distinta contribui para a redução do espanto, no entanto, esses são princípios separados no design da API. Os quatro princípios frequentemente apresentados como "bom design de API" são ( deste pdf - apenas uma instância dessa apresentação. Os links no final deste particular contribuem para uma boa leitura):

• Princípio da responsabilidade única
• Princípio aberto aberto
• SECO
• Princípio de menor espanto

É potencialmente surpreendente alguém ter uma aula que tenta fazer tudo - ou precisar de duas aulas para fazer uma única coisa. Da mesma forma, é potencialmente surpreendente que alguém mexa com os internos de maneiras estranhas sob as cobertas (acho que as aulas abertas no Ruby são uma fonte de espanto sem fim). Também é surpreendente encontrar dois métodos que aparentemente fazem a mesma coisa.

Como tal, o princípio de menor espanto subjacente aos outros designs de API - mas, por si só, não é suficiente para simplesmente dizer "não tem uma API surpreendente".

Leitura adicional (da perspectiva da interface do usuário) - um blog de desenvolvedores da IBM intitulado O usuário irritadiço: O princípio do mínimo de espanto

O princípio de menor espanto é quando você, como designer de API, impede seus usuários de dizerem WAT .

Alguns exemplos de espanto em diferentes 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

E há muitos outros exemplos em vários idiomas e APIs. Seu trabalho como gravador de API é evitar isso. As coisas devem ser nomeadas e digitadas de maneira que seja óbvio o que uma chamada para sua API fará. Inclua ampla documentação onde isso não for possível.

Basicamente, se as pessoas tiverem que ler sua documentação completamente para descobrir como ler o código escrito para sua API, provavelmente você está fazendo errado.

Aqui está um exemplo de "espanto" que aconteceu comigo recentemente. Eu me perdi na estrada, então parei e um tanto freneticamente (cheguei atrasado) perfurei um cruzamento no meu GPS. Cliquei em Ir e coloquei minhas mãos no volante - mas recebi um aviso alto (em tela cheia) de que o GPS deveria ser atualizado - exigindo que eu soubesse.

Meu pensamento era "você está brincando? Você está me dizendo isso agora? Eu preciso tirar minhas mãos do volante para reconhecer?".

Surpresa surge na interface (normalmente a interface do usuário, mas suponho que também possa ser uma API que se comporte de maneira inesperada). Eu diria que permeia também abaixo da interface, porque é necessário um software subjacente bem projetado para suportar uma interface realmente bem projetada.