หลักการของความประหลาดใจน้อยที่สุดคืออะไร?

ในการเขียนโปรแกรมสิ่งที่เรียกว่า Principle of Least ประหลาดใจ? แนวคิดนี้เกี่ยวข้องกับการออกแบบ API ที่ดีอย่างไร สิ่งนี้ใช้ได้กับการเขียนโปรแกรมเชิงวัตถุเท่านั้นหรือมันซึมซาบเทคนิคการเขียนโปรแกรมอื่น ๆ ด้วยหรือไม่ สิ่งนี้เกี่ยวข้องกับหลักการ "ทำสิ่งเดียวในวิธีการของคุณและทำได้ดีหรือไม่"?

หลักการของความพิศวงน้อยที่สุดใช้ได้กับกิจกรรมการออกแบบที่หลากหลาย - ไม่เพียง แต่ในการคำนวณ (แม้ว่าจะเป็นสิ่งที่น่าประหลาดใจที่สุดเกิดขึ้นบ่อยครั้ง)

พิจารณาลิฟต์ที่มีปุ่มถัดจากที่มีคำว่า "โทร" เมื่อคุณกดปุ่มโทรศัพท์สาธารณะจะดังขึ้น (แทนที่จะเรียกลิฟต์ไปที่ชั้นนั้น) นี้จะถือว่าน่าอัศจรรย์ การออกแบบที่ถูกต้องคือการวางปุ่มโทรติดกับโทรศัพท์แทนลิฟต์

จากนั้นให้นึกถึงหน้าเว็บที่มีหน้าต่างป๊อปอัปที่แสดงข้อผิดพลาดสไตล์หน้าต่างพร้อมปุ่ม 'ตกลง' คนคลิกที่ปุ่ม 'ตกลง' คิดว่ามันเป็นระบบปฏิบัติการและแทนที่จะไปที่หน้าเว็บอื่น สิ่งนี้ทำให้ผู้ใช้ประหลาดใจ

เมื่อพูดถึง API ...

• คิดเกี่ยวกับเมธอด toString () ที่แทนที่จะพิมพ์ฟิลด์กลับคืน "เพื่อนำไปใช้"
• วิธีการ equals () ที่ทำงานกับข้อมูลที่ซ่อนอยู่
• บางครั้งผู้คนพยายามใช้คลาสลิสต์ที่เรียงลำดับโดยการเปลี่ยนวิธีการเพิ่มเพื่อเรียก sort () บนอาเรย์หลังจากนั้น - ซึ่งน่าประหลาดใจเพราะเมธอด addควรจะผนวกเข้ากับรายการ - นี่เป็นสิ่งที่น่าประหลาดใจอย่างยิ่ง ไม่มีความรู้ว่ามีบางส่วนอยู่ด้านในลึกบางคนละเมิดสัญญาอินเตอร์เฟซ

การมีวิธีการที่ทำสิ่งหนึ่งที่แตกต่างมีส่วนช่วยลดความประหลาดใจอย่างไรก็ตามสิ่งเหล่านี้เป็นหลักการแยกต่างหากในการออกแบบ API หลักการทั้งสี่มักจะขนานนามว่า "การออกแบบ API ที่ดี" คือ (จากไฟล์ PDF นี้ - เป็นเพียงตัวอย่างหนึ่งของงานนำเสนอดังกล่าวลิงก์ในตอนท้ายของบทความนี้ทำเพื่อการอ่านที่ดี):

• หลักการความรับผิดชอบเดี่ยว
• หลักการเปิดปิด
• แห้ง
• หลักการของความประหลาดใจน้อยที่สุด

อาจเป็นเรื่องน่าประหลาดใจที่บางคนมีชั้นเรียนที่พยายามทำทุกอย่าง - หรือต้องการเรียนสองชั้นเพื่อทำสิ่งเดียว นอกจากนี้ยังเป็นที่น่าอัศจรรย์สำหรับบางคนที่จะยุ่งกับ internals ในรูปแบบแปลก ๆ ภายใต้ฝาครอบ (ฉันพบชั้นเรียนเปิดใน Ruby เป็นแหล่งของความประหลาดใจที่ไม่มีที่สิ้นสุด) นอกจากนี้ยังเป็นที่น่าอัศจรรย์ในการค้นหาสองวิธีที่ทำสิ่งเดียวกัน

ดังนั้นหลักการของความประหลาดใจอย่างน้อยก็เป็นไปตามการออกแบบ API อื่น ๆ แต่ตัวมันเองนั้นไม่เพียงพอที่จะพูดง่ายๆว่า "ไม่มี API ที่น่าอัศจรรย์"

อ่านเพิ่มเติม (จากมุมมอง UI) - บล็อกผู้พัฒนา IBM ชื่อผู้ใช้ที่บ้าๆบอ ๆ : 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 ของฉัน ฉันคลิกไปแล้ววางมือลงบนพวงมาลัย - แต่จากนั้นก็มีเสียงเตือน (เต็มหน้าจอ) ว่า GPS ควรได้รับการอัปเดต - ซึ่งต้องให้ฉันรับทราบ

ความคิดของฉันคือ "คุณล้อเล่นหรือไม่คุณกำลังบอกฉันตอนนี้หรือไม่ฉันต้องถอดมือออกเพื่อรับทราบ?"

พื้นผิวประหลาดใจในส่วนต่อประสาน (โดยทั่วไปคือ UI แต่ฉันคิดว่ามันอาจเป็น API ที่ทำงานในลักษณะที่ไม่คาดคิด) ฉันจะบอกว่ามันแทรกซึมด้านล่างของอินเทอร์เฟซเช่นกันเพราะมันใช้ซอฟต์แวร์พื้นฐานที่ออกแบบมาอย่างดีเพื่อรองรับอินเทอร์เฟซที่ออกแบบมาอย่างดี