Aracılığıyla paylaş

Özel Durumlar ve Performans

Uyarı

Bu içerik, Çerçeve Tasarım Yönergeleri: Kurallar, Deyimler ve Yeniden Kullanılabilir .NET Kitaplıkları için Desenler, 2. Sürüm'den Pearson Education, Inc.'in izniyle yeniden yazdırılır. Bu baskı 2008'de yayımlandı ve kitap o zamandan beri üçüncü baskıda tamamen revize edilmiştir. Bu sayfadaki bazı bilgiler güncel olmayabilir.

Özel durumlarla ilgili yaygın sorunlardan biri, düzenli olarak başarısız olan kod için özel durumlar kullanılırsa uygulamanın performansının kabul edilemez olmasıdır. Bu, geçerli bir endişedir. Bir üye özel durum fırlattığında, performansı kat kat daha yavaş olabilir. Ancak, hata kodlarını kullanmaya izinmeyen özel durum yönergelerine tam olarak uyarken iyi bir performans elde etmek mümkündür. Bu bölümde açıklanan iki desen bunu yapmanın yollarını önerir.

❌ Özel durumların performansı olumsuz etkileyebileceği endişeleri nedeniyle hata kodlarını KULLANMAYIN.

Performansı geliştirmek için, sonraki iki bölümde açıklanan Tester-Doer Desenini veya Try-Parse Desenini kullanmak mümkündür.

Tester-Doer Deseni

Bazen, bir istisna atan üyenin performansı, üyeyi ikiye bölerek iyileştirilebilir. Şimdi Add arabiriminin ICollection<T> yöntemine bakalım.

ICollection<int> numbers = ...
numbers.Add(1);

Yöntem Add, eğer koleksiyon salt okunursa hata verir. Yöntem çağrısının sık sık başarısız olması beklenen senaryolarda bu bir performans sorunu olabilir. Sorunu azaltmanın yollarından biri, bir değer eklemeye çalışmadan önce koleksiyonun yazılabilir olup olmadığını test etmektir.

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

Örneğimizde özelliği IsReadOnlyolan bir koşulu test etmek için kullanılan üye, test eden olarak adlandırılır. Örneğimizdeki Add yöntemini içeren potansiyel bir fırlatma işlemini gerçekleştirmek için kullanılan üye, doer olarak adlandırılır.

✔️ Özel durumlarla ilgili performans sorunlarını önlemek için ortak senaryolarda özel durumlar oluşturabilecek üyeler için Tester-Doer Desenini GÖZ ÖNÜNDE BULUNDURUN.

Try-Parse Deseni

Son derece performansa duyarlı API'ler için, önceki bölümde açıklanan Tester-Doer Deseninden daha hızlı bir desen kullanılmalıdır. Bu desen, iyi tanımlanmış bir test durumunu üye semantiğinin bir parçası haline getirmek için üyenin adını ayarlamayı gerektirir. Örneğin, DateTime bir dize ayrıştırma başarısız olursa özel durum fırlatan bir Parse yöntemi tanımlar. Ayrıca ayrıştırmaya çalışan ilgili TryParse bir yöntemi tanımlar, ancak ayrıştırma başarısız olursa false döndürür ve bir out parametre kullanarak başarılı bir ayrıştırma sonucunu döndürür.

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

Bu deseni kullanırken, deneme işlevini katı terimlerde tanımlamak önemlidir. Üye iyi tanımlanmış deneme dışında herhangi bir nedenle başarısız olursa, üye yine de karşılık gelen bir özel durum oluşturmalıdır.

✔️ İstisnalarla ilgili performans sorunlarını önlemek için, yaygın senaryolarda istisna oluşturabilecek üyeler için Try-Parse Desenini düşünün.

✔️ DO, bu deseni uygulayan yöntemler için "Try" ön ekini ve Boole dönüş türünü kullanın.

✔️ DO, Try-Parse Desenini kullanarak her üye için özel durum oluşturan bir üye sağlar.

Porsiyonlar © 2005, 2009 Microsoft Corporation. Tüm hakları saklıdır.

Pearson Education, Inc. tarafından Krzysztof Cwalina ve Brad Abrams'ın Yeniden Kullanılabilir .NET Kütüphaneleri için Çerçeve Tasarım Yönergeleri: Sözleşmeler, Deyimler ve Kalıplar, 2. Baskı eserinden izniyle yeniden basılmıştır. Addison-Wesley Professional tarafından Microsoft Windows Geliştirme Serisi kapsamında 22 Ekim 2008'de yayımlanmıştır.

Ayrıca bakınız

  • Last updated on