API Tasarımının Altın Kuralı

API tasarımı, özellikle büyük ölçekte zordur. Yüzlerce veya binlerce kullanıcıya sahip olacak bir API tasarlıyorsanız, gelecekte bunu nasıl değiştirebileceğinizi ve değişikliklerinizin istemci kodunu bozup bozamayacağını düşünmelisiniz. Bunun ötesinde, API'nizin kullanıcılarının sizi nasıl etkilediğini düşünmelisiniz. API sınıflarınızdan biri dahili olarak kendi yöntemlerinden birini kullanıyorsa, bir kullanıcının sınıfınızı alt sınıflara ayırıp onu geçersiz kılabileceğini ve bunun felaketle sonuçlanabileceğini hatırlamanız gerekir. Bazı kullanıcılarınız ona farklı bir anlam verdiği için bu yöntemi değiştiremezsiniz. Gelecekteki dahili uygulama seçenekleriniz, kullanıcılarınızın insafına kalmıştır.

API geliştiricileri bu sorunu çeşitli şekillerde çözer, ancak en kolay yol API'yi kilitlemektir. Java'da çalışıyorsanız, sınıflarınızın ve yöntemlerinizin çoğunu final yapmak isteyebilirsiniz. C#'da sınıflarınızı ve yöntemlerinizi sealed hale getirebilirsiniz. Kullanmakta olduğunuz dil ne olursa olsun, API'nizi bir singleton aracılığıyla sunmaya veya statik fabrika yöntemlerini kullanmaya cazip gelebilirsiniz, böylece onu davranışı geçersiz kılabilecek ve kodunuzu daha sonra seçimlerinizi kısıtlayabilecek şekillerde kullanabilecek kişilerden koruyabilirsiniz. Bütün bunlar makul görünüyor, ama gerçekten öyle mi?

Son on yılda, birim testinin uygulamanın son derece önemli bir parçası olduğunu yavaş yavaş fark ettik, ancak bu ders endüstriye tam olarak nüfuz etmedi. Kanıtlar etrafımızda. Üçüncü taraf API kullanan rastgele denenmemiş bir sınıf alın ve bunun için birim testleri yazmaya çalışın. Çoğu zaman başın belaya girecek. API'yi kullanan kodun ona yapıştırıcı gibi yapıştığını göreceksiniz. Kodunuzun bunlarla olan etkileşimlerini hissedebilmeniz veya test için dönüş değerleri sağlayabilmeniz için API sınıflarının kimliğine bürünmenin bir yolu yoktur.

Zamanla, bu daha iyi olacak, ancak yalnızca API'leri tasarlarken testi gerçek bir kullanım durumu olarak görmeye başlarsak. Ne yazık ki, kodumuzu test etmekten biraz daha fazla ilgili. API Tasarımının Altın Kuralı tam da bu noktada devreye girer: Geliştirdiğiniz bir API için testler yazmak yeterli değildir; API'nizi kullanan kod için birim testleri yazmanız gerekir. Bunu yaptığınızda, kullanıcılarınızın kodlarını bağımsız olarak test etmeye çalıştıklarında üstesinden gelmek zorunda kalacakları engelleri ilk elden öğrenirsiniz.

Geliştiricilerin API'nizi kullanan kodu test etmesini kolaylaştırmanın tek bir yolu yoktur. static, final ve sealed doğal olarak kötü yapılar değildir. Zaman zaman faydalı olabilirler. Ancak test konusunun farkında olmak önemlidir ve bunu yapmak için bunu kendiniz deneyimlemelisiniz. Bir kez sahip olduğunuzda, diğer herhangi bir tasarım zorluğunda olduğu gibi ona da yaklaşabilirsiniz.

Michael Feathers Tarafından