C# Statik Değişken ve Metotlar Kötü mü? Derek Comartin Açıklıyor (Video Çözümlemesi)

Bir Statik Yöntem Nasıl Sorunlu Hale Gelir?

Videonun başında, Derek Is18YearsOrOlder adlı bir statik metoda dalmaktadır. Bu yöntem bir DateTime birthDate alır ve birinin en az 18 yaşında olup olmadığını kontrol eder. Mevcut tarihi karşılaştırmak için DateTime.UtcNow kullanır. Basit görünüyor, değil mi?

Ama Derek'in belirttiği gibi, bu yöntem belirleyici değildir. 0:50'de, DateTime.UtcNow kullanılmasının yönteminin, çalıştırıldığında farklı sonuçlar döndüreceği anlamına geldiğini vurgular. Bu, birim testlerinde büyük bir sorundur ve kodda beklenmedik davranışlara neden olur.

Bu durumda, yöntem saf bir işlev gibi görünse de değildir. Derek, saf bir yöntemin aynı parametrelerle her çağrı yapıldığında aynı değeri döndürmesi gerektiğini açıklar. Ama burada, güncel tarih sürekli değiştiği için geri dönüş değeri de değişir.

Bu, zamana veya uygulama alanı durumuna bağlı bir durumsa, bu bir yan etki oluşturan fonksiyona yol açabilir.

Statik Yöntemleri Test Edilebilir ve Öngörülebilir Yapmak

Derek'in bir sonraki noktası kritiktir: Belirleyici olmaktan kurtulmanın yolu, DateTime.UtcNow'a bağımlılığı ortadan kaldırmaktır. Derek, bunun yerine, statik bir sınıf veya bir arayüz uygulaması kullanarak bir zaman sağlayıcısı enjekte etmeyi gösterir. Bu, fonksiyonu belirleyici hale getirir — her zaman aynı girdiyi geçtiğinizde aynı çıktıyı alırsınız.

PlaceOrder sınıfında, Cuma günleri işlenen siparişlerin yüzde 50 indirim alıp almadığını test etmek için sahte bir tarih sağlayıcısı sunar. Bu, sistem zamanına bağlı mantığı sıkı bir şekilde yazmak yerine, yöntemi daha güvenilir ve test edilebilir hale getirir.

Bir davranışı izole ederek ve iş mantığında doğrudan statik yöntemlere referansta bulunmaktan kaçınarak, Derek, temiz kodun nasıl korunduğunu ve test edilebilirliğin nasıl sürdürüldüğünü gösterir.

Sıkı Bağlılık ve Statik Yöntemler

Derek bu noktada, statik yöntemlere dayanmanın genellikle sıkı bağlılık getirdiğine dikkat çeker. Eğer doğrudan DateTime.UtcNow kullanıyorsanız, o uygulamaya bağlısınız — onu geçersiz kılamazsınız veya yazılımsal olarak temsil edemezsiniz.

Bu, çünkü bu gibi statik üyeler uygulamanız genelinde küreseldir. Kod tabanınız statik alanları veya statik özellikleri yoğun bir şekilde kullanıyorsa, davranışı değiştirmek veya bağımlılık enjekte etmek daha zor hale gelir ve nesne yönelimli programlamanın temel ilkelerini bozabilir.

Aynı zamanda esnekliği de kaybedersiniz çünkü statik alanı örnek değişkeni veya enjeksiyon servisi gibi başka bir uygulama ile değiştiremezsiniz.

Statik Değişkenlerle Küresel Durum Sorunu

Şimdi Derek, statik değişkenlere odaklanır ve bu noktada konuşma ciddi olur.

Bir Global sınıfında kullanılan bir statik önbellek örneği sunar. Statik değişkenlerle ilgili en büyük sorunun bilinmeyen durum olduğunu açıklar. Çalışma sırasında, statik alanın başlatılıp başlatılmadığından emin olamazsınız. Bu belirsizlik, özelikle değiştirilmiş statik bir int veya string adı olduğunda özellikle riske atılmıştır.

Bu senaryo, geliştiricilerin o değişkende yalnızca bir kopya paylaşıldığını ve iş parçacığı güvenliğine dikkat etmeyi unutmaları durumunda daha kötü hale gelir.

Çoklu İş Parçacıklı Kodda Statik Alanlar ve İş Parçacığı Güvenliği

Derek başka bir endişeyi gündeme getirir: Statik değişkenleri çoklu iş parçacıklı ortamlarda kullanmak. Static List<Customer> örneğini, Parallel.For ile eşzamanlı olarak kullanılmasının bir örneğini verir. Kod, statik alanın iş parçacığı güvenli olmaması nedeniyle çöker.

Bunu çözmek için, bir ConcurrentBag<Customer> kullanır, .NET'te bulunan bir iş parçacığı güvenli koleksiyonu. Statik verilere birden fazla iş parçacığı ile güvenli bir şekilde erişmeyi sağlar.

Onun noktası net: Statik değişkenleri iş parçacıkları arasında kullanıyorsanız, onların iş parçacığı güvenli olduklarından emin olmanız gerekiyor. Aksi takdirde programınız beklenmedik şekilde davranabilir veya hatta çökebilir.

Statik Yöntemlerin Güvenli Kullanımı

Derek daha sonra bir statik yöntemini güvenli ve etkili kullanımdan bahseder: basit bir yardımcı yöntem olan MilesToKilometers. Bir int miles alır ve dönüşümden sonra bir double değer döndürür. Bu yöntem belirleyicidir — aynı int değeri için her zaman aynı sonucu alırsınız.

Bu tür bir yöntem, statik olmayan alanlara bağlı değildir, paylaşılan verileri değiştirmez ve bilinmeyen bir durumdan etkilenmez. Bu, statik anahtar kelimeyi C# içinde doğru bir şekilde kullanmanın harika bir örneğidir.

C# Bağlamında Statik Anlamak

C#'ta, statik anahtar kelime sınıflara, alanlara, yöntemlere, yapıcılara ve özelliklere uygulanabilir. Derek dolaylı olarak şu kavramlardan bahseder:

• Statik sınıf: Başlatılamayan ve yalnızca statik üyeler içerebilen bir sınıf.

• Statik alanlar: Statik anahtar kelime ile deklar edilmiştir — her uygulama alanında yalnızca bir kopya vardır.

• Statik yapılandırıcı: Sınıf ilk kez erişildiğinde yalnızca bir kez çalışır.

• Statik void Main: Çoğu C# uygulamasının giriş noktasıdır, statik yöntemlerin nasıl önemli olabileceğini gösterir.

• Statik int, statik string: Sınıfın tüm örneklerine ortak verileri saklayan statik alanlar örnekleri, ya da aslında bir örnek gerektirmeyenler.

Nesne yapılandırıcılarının her nesne oluşturduğunuzda çalışmasından farklı olarak, statik yapılandırıcı yalnızca sınıf seviyesindeki kaynakları bir kez başlatır.

Bu ayrım, geliştiricilerin örnek değişken ile statik değişken kullanımı hakkında ne zaman karar vermesi veya paylaşılan üye değişkenlerini kapsüllerken özellik erişicilerini kullanımı gerektiğine karar vermesine yardımcı olur.

Derek'ten Son Alınacaklar

Derek, geliştiricilerin statik üyelere karşı dikkat uyarısı yapmasının ana nedenlerini özetliyor:

• Sıkı bağlılık — o statik yöntem veya alanın davranışına takılıp kalırsınız.

Nondeterministik davranış

• Küresel değişken durum — değerin ne olduğunu veya kimin değiştirdiğini bilmiyorsunuz.

• Eşzamanlılık sorunları — çoklu iş parçacıklı bir kodda paylaşılan verilere güvensiz erişim.

Ancak, Derek'in dediği gibi, statik kötü değildir. Doğru kullanıldığında güçlüdür — özellikle yardımcı işlevlerde, paylaşılan sabitlerde veya gerçekten küresel ayarlarda. Sadece durumu dikkatle yönetmeniz ve değiştirilebilir veya sistem özgü davranışlara bağımlı olmaktan kaçınmanız gerekir.

Sonuç

Statik değişkenler ve yöntemler C#'ta iki ucu keskin kılıç gibidir. Derek Comartin kesinlikle açık bir şekilde, onların özünde kötü olmadığını — ama düşünceli bir kullanıma ihtiyaç duyduklarını açıklar. Statik alanları ve statik sınıfları, nesne durumuna bağlı olmayan paylaşılan veri veya işlevselliğe ihtiyaç duyduğunuzda kullanın. Ancak, zamanı, sistem durumunu veya esneklik gerektiren şeyler için kullanmaktan kaçının.

Yani bir nesne oluşturmadan veya statik bir alana erişmeden önce, kapsama, test edilebilirlik, iş parçacığı güvenliği ve kodun bir kopya mı yoksa birden fazla kopya mı gerektirdiğine dair düşünün.

Derek Martin'in video yu CodeOpinion YouTube kanalında izleyin. Daha fazla içgörüleri temiz mimari, yazılım tasarımı ve gerçek dünya C# uygulamaları hakkında bulacaksınız.