Bir arayüzü nasıl geliştirir ve değiştirirsiniz?

Arayüzünüz olduğunu söyleyin IFoo:

public interface IFoo {
    void Bar(string s);
    int Quux(object o);
}

API'nizin 2. sürümünde, Glargbu arayüze bir yöntem eklemeniz gerekir . Bunu, mevcut API kullanıcılarınızı kırmadan ve geriye dönük uyumluluğu koruyarak nasıl yaparsınız? Bu temel olarak .NET'e yöneliktir, ancak diğer çerçevelere ve dillere de uygulanabilir.

API'nizin 2. sürümünde, Glargbu arayüze bir yöntem eklemeniz gerekir .

Niye ya?

Bir API ile kullanım için tanımlanan arayüzlerin tamamen farklı iki rolü vardır:

1. Bağımlılık inversiyonu - bu tür arayüzler API'niz tarafından tüketilir. İstemci kodunun eklentiler oluşturmasını sağlar.
2. Soyutlama - bu tür arayüzler API'niz tarafından döndürülür ve döndürülen nesnelerin uygulama ayrıntılarını gizler.

Şimdi bir API'nin belirli bir sürümü için , aynı arayüz her ikisi gibi davranabilir. Yine de, gelecek sürümlerde, bu ayrılabilir.

1. Tükettiğin arayüzden daha fazla bilgi çıkarmak istiyorsun. Performansı artırmak veya esneklik veya başka bir şey eklemek için. Muhtemelen eskisinden türetilmiş yeni bir arayüz tanımlayın ve onu tüketen ayrı bir yöntem oluşturun. AFAIK çoğu .NET dilinde yöntem aşırı yüklenmesine izin verir, bu yüzden fazla dağınıklık olmadan gerçekleşebilir.

2. API’nizden “daha ​​zengin” bir nesnenin soyutlamasını, yani “daha ​​fazla geri” döndürmek istiyorsunuz. Burada iki seçeneğin var:

   • Müşteri kodunun arayüzün kendi uygulayıcılarına sahip olmayacağını makul bir şekilde kabul edebilirsiniz. Bu varsayım altında, uzantılarınızı mevcut arayüze eklemek güvenlidir.

   • Mümkünse öncekinden türetilmiş yeni bir arayüz tanımlayın. Eğer böyle bir türev imkansız ise, yeni arayüzün örneklerini sorgulamak için ayrı yöntemler oluşturun veya kompozisyon kullanın:

     interface MyNewInterface extends MyOldInterface { 
          FancyNewInterface getFancyShit();
     }
     

DirectX, arayüzlerine sürüm numaraları ekledi. Senin durumunda, çözüm gibi bir şey olurdu

public interface IFoo2 : IFoo
{
    void Glarg();
}

API, hala IFoo'ya ve IFoo2'ye yalnızca IFoo2 işlevselliğinin gerekli olduğu yöntemlerde vb.

API uygulaması, bir IFoo parametre nesnesinin, IFoo2 için yöntem anlamının farklı olması durumunda, IFoo2 nesnesinin gerçekte IFoo2'yi uygulayıp uygulamadığını kontrol etmelidir.

API'nize yeni bir yöntem (veya yöntemler) eklemek, mevcut API üzerinde herhangi bir yan etkisi olmayacak şekilde yapılmalıdır. En önemlisi, eski API'yi yeni API yokmuş gibi kullanmaya devam eden birinin bundan etkilenmemesi gerekir. Eski API'yi kullanmanın da yeni API üzerinde beklenmeyen bir yan etkisi olmamalıdır .

API'deki mevcut yöntemlerden herhangi biri yenileriyle değiştiriliyorsa, bunları hemen kaldırmayın. Bunları kullanımdan kaldırılmış olarak işaretleyin ve ne kullanılması gerektiği konusunda bir açıklama yapın. Bu kod kullanıcılarınıza gelecekteki sürümlerin uyarmadan kodlarını kırmak yerine artık desteklemeyebileceğini bildirir.

Yeni ve eski API'ler uyumsuzsa ve istenmeyen yan etkiler olmadan birlikte yaşayamazsa, bunları ayırın ve yeni API kabul edilecekse eski API'nin tamamen emekli olması gerektiğini belgeleyin. Her ikisini de kullanmaya çalışan ve çalışmadığı zaman sinir bozan biri olacağı için bu daha az arzu edilir.

Özellikle .NET ile ilgili sorular sorduğunuzdan , (aşağıdaki örnekte kullanılan) 'a bağlantı veren .NET'teki değer kaybı hakkında bu makaleyi okumak isteyebilirsiniz ObsoleteAttribute:

using System;

public sealed class App {
   static void Main() {      
      // The line below causes the compiler to issue a warning:
      // 'App.SomeDeprecatedMethod()' is obsolete: 'Do not call this method.'
      SomeDeprecatedMethod();
   }

   // The method below is marked with the ObsoleteAttribute. 
   // Any code that attempts to call this method will get a warning.
   [Obsolete("Do not call this method.")]
   private static void SomeDeprecatedMethod() { }
}

Genel arayüz değişiklikleri kırılmayı içerir. Ortak strateji, bunları yalnızca büyük sürümlerde ve donma süresinden sonra yapmaktır (bu nedenle heves içinde olmaz). Sizi yeni bir arayüze eklemeler ekliyorsanız (ve uygulamanız her ikisini de aynı sınıfa sağlayabilir) müşterilerinizi kırmadan kurtulabilirsiniz. Bu ideal değil ve yapmaya devam ederseniz bir karmaşa yaşarsınız.

Yine de başka türlü değişikliklerde (yöntemlerin kaldırılması, imzaların değiştirilmesi) sıkışmış durumdasınız.

Bir arayüz bir sözleşmedir, bu yüzden versiyonlamaya sahip olmamalıdır. Bir futbolcu yeni bir sözleşme yaparsa ne olur? Eskisi hala geçerli mi? Hayır. Arayüz değiştirilirse, sözleşme değişir ve önceki sözleşme (arayüz) artık geçerli değildir.

IFoo2 stratejisini kullanabilseniz de, nihayetinde bu durum dağınık olacak:

• IFoo2
• IFoo3
• IFoo4
• vb.

Yuck.

Bir API farklı. Kullanmak için kod kütüphanesi veriyorum. Gelecek ay size güncellenmiş bir kütüphane veriyorum. Başka bir posterin dediği gibi, zaten kullandığımı kırma, sadece yeni işlevler / yöntemler ekle.

Bir şeyi sürümlendirmek istiyorsanız, arayüz yerine bir abtract sınıfı kullanın.