En az şaşkınlık ilkesi nedir?

Programlamada en az şaşkınlık ilkesi ne denir? Bu konseptin iyi API'ler tasarlama ile ilgisi nedir? Bu sadece nesne yönelimli programlama için uygulanabilir mi yoksa başka programlama tekniklerine de nüfuz ediyor mu? Bu, "yönteminizde tek bir şey yapmak ve iyi yapmak" ilkesiyle mi ilgili?

En Az Şaşkınlık İlkesi, sadece hesaplamada değil (çoğu zaman en şaşırtıcı şeylerin gerçekleştiği yer olmasına rağmen) çok çeşitli tasarım faaliyetlerine uygulanabilir.

Yanında "ara" yazan düğmeli bir asansör düşünün. Düğmeye bastığınızda, ödemeli telefon çalar (asansörü o kata çağırmak yerine). Bu şaşırtıcı olarak kabul edilir. Doğru tasarım asansörün yerine telefonun yanındaki çağrı düğmesini koymak olacaktır.

Ardından, üzerinde 'ok' düğmesi bulunan bir pencere stili hatası gösteren bir açılır pencere içeren bir web sayfasını düşünün. İnsanlar işletim sistemi için olduğunu düşünerek 'tamam' düğmesini tıklar ve bunun yerine başka bir web sayfasına giderler. Bu kullanıcıyı şaşırtıyor.

Bir API'ye gelince ...

• Alanları yazdırmak yerine "uygulanacak" duruma geri döndüren bir toString () yöntemini düşünün.
• Gizli bilgiler üzerinde çalışan bir equals () yöntemi.
• Bazen insanlar daha sonra dizideki sort () işlevini çağırmak için add yöntemini değiştirerek sıralanmış bir sınıf sınıfını uygulamaya çalışırlar; bu, add yönteminin listeye eklenmesi gerektiği için şaşırtıcıdır; derinlerde bir yerde birisinin ara yüz sözleşmesini ihlal ettiği bilgisi olmadan.

Farklı bir şey yapan bir yönteme sahip olmak şaşkınlığın azaltılmasına katkıda bulunur, ancak bunlar API tasarımında ayrı ilkelerdir. Genellikle "iyi API tasarımı" olarak adlandırılan dört ilke ( bu pdf'den - böyle bir sunumun yalnızca bir örneği. Bu özel olanın sonundaki bağlantılar iyi okuma için yapar):

• Tek sorumluluk prensibi
• Açık kapalı prensibi
• KURU
• En az şaşkınlık ilkesi

Birisinin, her şeyi yapmaya çalışan bir sınıfa sahip olması ya da tek bir şeyi yapması için iki sınıfa ihtiyaç duyması şaşırtıcı olabilir. Aynı şekilde, birisinin iç kısımları kapakların altında tuhaf yollarla karıştırması potansiyel olarak şaşırtıcı (Ruby'de açık sınıfları hiç bitmeyen bir şaşkınlık kaynağı olarak görüyorum). Aynı şekilde, görünüşe göre aynı şeyi yapan iki yöntem bulmak şaşırtıcı.

Bu nedenle, en az şaşkınlık ilkesi, diğer API tasarımlarının temelini oluşturuyor - ancak kendisi, sadece "şaşırtıcı bir API yok" demek yeterli değil.

Daha fazla okuma (UI perspektifinden) - “ Asıl Şaşkınlık İlkesi ” başlıklı IBM geliştirici blogu

En az şaşkınlığın ilkesi, bir API tasarımcısı olarak, kullanıcılarınızın WAT demesini engellemenizdir .

Farklı dillerde bazı şaşkınlık örnekleri.

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

Ve çeşitli dillerde ve API'lerde daha pek çok örnek var. Bir API yazarı olarak işiniz bunu engellemektir. İşler, API'nize yapılan bir aramanın ne yapacağı açıkça belli olacak şekilde adlandırılmalı ve yazılmalıdır. Bunun mümkün olmadığı yerlerde yeterli miktarda dokümantasyon ekleyin.

Temel olarak, insanlar API'niz için yazılmış kodun nasıl okunacağını bulmak için dokümanlarınızı baştan sona okumak zorunda kalırlarsa muhtemelen yanlış yapıyorsunuzdur.

İşte son zamanlarda başıma gelen bir "şaşkınlık" örneği. Yolda kayboldum, o yüzden kenara çektim ve biraz çılgınca (geç kaldım) GPS'ime kesiştim. Git'i tıklattım ve ellerimi tekrar tekerleğe koydum - ancak GPS'in güncellenmesi gerektiği konusunda yüksek sesli (tam ekran) bir uyarı aldım - onaylamamı istedi.

Düşüncem şuydu: "Dalga mı geçiyorsun? Bana bunu şimdi mi söylüyorsun? Onaylamak için ellerimi direksiyondan çekmem gerekiyor?".

Arayüzdeki şaşkınlık yüzeyleri (tipik olarak UI, ancak sanırım beklenmedik şekilde davranan bir API olabilir). Arayüzün altına da nüfuz edeceğini söyleyebilirim, çünkü gerçekten iyi tasarlanmış bir arayüzü desteklemek için iyi tasarlanmış bir temel yazılımı kullanıyor.