가장 놀라운 원리는 무엇입니까?

프로그래밍에서 Least Astonishment의 원리는 무엇입니까? 이 개념은 좋은 API 디자인과 어떤 관련이 있습니까? 이것이 객체 지향 프로그래밍에만 적용 가능한가? 아니면 다른 프로그래밍 기술에도 스며 들어 있는가? 이것은 "방법에서 하나의 일을하고 잘하는 것"의 원칙과 관련이 있습니까?

최소 놀랍게도는 컴퓨팅뿐만 아니라 (가장 놀라운 일이 일어나는 경우가 많음) 광범위한 설계 활동에 적용 할 수 있습니다.

옆에 "전화"라고 표시된 버튼이있는 엘리베이터를 고려하십시오. 버튼을 누르면 공중 전화가 울립니다 (엘리베이터를 해당 층으로 불러오는 대신). 이것은 놀라운 것으로 간주됩니다. 올바른 디자인은 엘리베이터가 아닌 전화기 옆에 통화 버튼을 배치하는 것입니다.

다음으로 '확인'버튼이있는 창 스타일 오류를 표시하는 팝업 창이있는 웹 페이지를 생각해보십시오. 사람들은 '확인'버튼을 클릭하여 운영 체제 용이라고 생각하고 대신 다른 웹 페이지로 이동합니다. 이것은 사용자를 놀라게합니다.

API에 관해서는 ...

• 필드를 출력하는 대신 "구현"을 돌려주는 toString () 메소드를 생각해보십시오.
• 숨겨진 정보에서 작동하는 equals () 메소드.
• 때때로 사람들은 add 메소드를 배열에서 sort ()를 호출하도록 정렬하여 정렬 된 목록 클래스를 구현하려고 시도합니다 .add 메소드 가 목록에 추가되어야하기 때문에 놀랍습니다. 내부 어딘가에 누군가가 인터페이스 계약을 위반했다는 것을 알지 못했습니다.

한 가지 뚜렷한 일을하는 방법을 사용하면 놀라움이 줄어드는 데 도움이되지만, API 디자인에서 별도의 원칙입니다. "좋은 API 디자인"으로 자주 선전되는 네 가지 원칙은 다음과 같습니다 ( 이 PDF 에서 이러한 프레젠테이션의 한 인스턴스에 불과합니다.이 특정 끝에있는 링크는 읽기에 적합합니다).

• 단일 책임 원칙
• 공개 폐쇄 원칙
• 마른
• 놀랍지 않은 원리

누군가가 모든 일을하려고하는 수업을하거나 하나의 일을하기 위해 두 개의 수업이 필요한 것은 놀라운 일입니다. 마찬가지로 누군가가 덮개 아래에서 이상한 방식으로 내부를 망치는 것은 잠재적으로 놀랍습니다 (루비에서 열린 클래스는 끝없는 놀라움의 원천입니다). 마찬가지로 똑같은 일을하는 두 가지 방법을 찾는 것도 놀랍습니다.

따라서 가장 놀랍게도라는 원칙은 다른 API 디자인의 기초가되지만, 그 자체로는 단순히 "놀라운 API가 없다"고 말하는 것만으로는 충분하지 않습니다.

더 자세한 내용 (UI 관점에서)-IBM 개발자 블로그 : The cranky user : The Principle of Least Astonishment

API 디자이너로서 사용자가 WAT 를 말하지 못하게 할 때 가장 놀랍게하는 원리는 다음과 같습니다 .

다양한 언어로 된 놀랍게도 몇 가지 예.

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

그리고 다양한 언어와 API로 더 많은 예제가 있습니다. API 작성자로서의 일은 이것을 방지하는 것입니다. API 호출이 무엇을하는지 분명하게 알 수있는 방식으로 이름을 지정하고 입력해야합니다. 이것이 불가능한 곳에 충분한 문서를 포함 시키십시오.

기본적으로 사람들이 API 용으로 작성된 코드를 읽는 방법을 파악하기 위해 문서를 철저히 읽어야하는 경우 아마도 잘못하고있을 것입니다.

최근에 나에게 일어난 "놀랍게도"의 예가 있습니다. 나는 길에서 길을 잃었으므로 GPS를 가로 질러 교차로 약간 미친 듯이 (나는 늦었다) 구멍을 뚫었다. Go를 클릭하고 바퀴에 손을 대고 GPS를 업데이트해야한다는 큰 (전체 화면) 경고 메시지가 표시됩니다.

내 생각은 "농담이야? 지금 나 한테 말하고 있니? 인정하기 위해 바퀴에서 손을 떼야 돼?"

인터페이스에서 놀랍게도 표면 (일반적으로 UI이지만 예기치 않은 방식으로 작동하는 API 일 수 있다고 생각합니다). 인터페이스 아래로도 퍼져 있다고 생각합니다. 제대로 설계된 인터페이스를 지원하려면 잘 설계된 기본 소프트웨어가 필요하기 때문입니다.